This Festive Season, enjoy 10% discount on all courses Use Coupon NY10 Click to Copy

Search

Series List

How Not to be Agile –The Business Case

Is Agile Everything?‘How Not to be Agile’ may seem a strange title for the blogs mentioning about how good Agile is!‘How Not to be Agile’ may seem a strange title for a series of articles about how good Agile is!  However, what I intend to do over this series of articles is to share with you the misinterpretations, omissions and mistakes that people make that significantly reduces the potential benefits for an organisation, or part of it, when it embarks on an Agile Transformation.Agile Transformation is not easy!  Yes, the ‘mechanics’ of all the Agile frameworks are relatively straightforward to implement, given that people are trained adequately.  However, the root cause of just about all the problems that I have come across is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.Last time, I discussed the potential pitfalls of not having a suitable and visible Vision and Objectives for whatever it is that we are trying to achieve, be it a new product, a major change to an existing product or the Agile transition itself.This time, I will cover some of the omissions, misunderstandings and malpractices that I have come across with respect to the Business Case; an overall product development ‘document’ with which we can track whether the ongoing development is likely to meet the business value outlined or specifically stated in the development Objectives for a reasonable cost; it is no use developing a product for $1 million dollars if it will take 10 years of product use before it pays for itself.I will start with a description of an Agile Business Case and then give examples of what has and could go wrong.What is the Business Case?Having achieved an agreed Vision and Objectives, the business stakeholders and development team need to quantify the business value that is expected from the product, in what timescale, and the estimates of how much it will cost to develop so that that the business stakeholders can determine whether the development is justified from a business point of view.These estimates are recorded in the Business Case; a cost-benefit analysis. In the past, in an effort to reduce development business risk as much as possible, some companies produced a detailed, task level, project plan with all the ‘who will do what and when’, factoring in known team member holidays etc.  By this means, they hoped to establish the probable costs of the development with a high degree of accuracy.  However, I have never seen the expected business benefits undergo such a rigorous analysis.Also, I have never seen the Business Case updated periodically during the development so that it can be determined whether the development is still justifiable.This way of producing a Business Plan usually involves a ‘development expert’ to do the technical estimations and takes a significant amount of time during which no business benefit is being accrued.What is an Agile Business Case?“Therefore, ‘experts’ are asked for their opinion about probable or possible costs for different ways of solving the problem:Develop the product from ‘scratch’ – usually the most expensive optionUse an existing product as a ’base’ and modify/configure it – the next most expensive optionOutsource the development – ‘passing risks to some other company’ – the costs can vary significantly depending on the contract type.From these ‘guesstimates’, the development Sponsor can take a decision as to which development option to take.  I will discuss Agile Roles in a later article.There is always another option for the Sponsor to take – ‘Do Nothing’; especially if the probable cost-benefit analysis indicates little Return-on-Investment.If the initial, ‘guesstimate’, Business Case cost-benefit analysis indicates that it may be worthwhile continuing with development,we can start gathering requirements.What is Agile Business Case Lifecycle?Once the initial Agile Business Case has been created it is not ‘set in stone’; like most other things in an Agile environment, it is subject to change as we learn during the development. Indeed, I use a set of development ‘document’ templates, which includes an Agile Business Case, that all have ‘This is Subject to Change’ printed in red at the top and bottom of each page.Post Product Backlog CreationThe Product Backlog, which I shall discuss in my next article, is a list of ‘requirements’ that have been ordered by business value and estimated.These estimates, that have been done by the development team, can replace the costs section of the initial Business Case. The initial Business Case expected benefits can be assessed by a wider stakeholder population and either confirmed or modified.The cost-benefit analysis for the modified Business Case values can be used to, again, assess whether it is advisable to continue the development, modify the Vision and Objectives to obtain a viable Business Case or cancel the development.The time taken from establishing the Vision to achieving this first modified Agile Business Case should be no longer than 2 to 3 weeks; usually, a lot shorter time than is usually taken in a traditional product development environment.At the End of Development TimeboxesA Development Timebox is the short, 2 to 3 week period during which the development team completely develop a subset of the ‘requirements’ and what has been developed demonstrated to the relevant stakeholders.  Most of you will recognise this as the definition of a Sprint from Scrum; other Agile Frameworks use different names; I will use the term Sprint during the rest of this article because it is quicker to type!It is recommended that the Agile Business Case be ‘reviewed’ at the end of each Sprint, during the Sprint Review, for the first few Sprints; it is during these first Sprints that the learning curve is steepest. The estimated costs against the actual costs can be assessed and the Agile Business Case updated if necessary.  Obviously, assessing the actual benefits accrued at this early stage in development is almost impossible.  However, a view can be taken on the new cost-benefit analysis as to whether to continue development.Remember:                                                                                                   ‘Fail Fast’Once the initial learning has been done, most organisations revert to reviewing the Agile Business Case during the Increment Reviews, done just before a group of functionalities is placed ‘live’; probably every 2 or 3 months.Case Study 1:Many years ago, I was asked to help a team who were building a financial products sales system to replace a company’s current system.  The ‘need’ that prompted this development was regulatory in that there had been ‘mis-selling’ of some of the financial products and the government had told the whole sector that they had 6 months ‘to clean up their act’.The company’s current system was based on an ageing mainframe and it was decided that as well as trying to incorporate new regulatory business rules into the sales system, the whole process would be ‘transferred’ to a system using ‘modern’ technology so that additional sales processes could be incorporated, taking advantage of the capabilities of the new technology.The company mitigated some of the huge risks that they were taking on by outsourcing the development on a fixed price basis; the outsource company decided that ‘Managed RAD’ (the precursor of Agile) was the way to go; I was helping the outsource supplier company team.The ‘Vision’ was clear:“To develop a financial products sales system that complies with Government regulation in 6 months so that the company can continue to sell financial products”There was an onsite, senior salesman from the client company to give the requirements for the new system; the equivalent of a Scrum Product Owner.Unfortunately, no one had taken the time to produce a Business Case; it was obvious wasn’t it? ‘New system in 6 months or die’!The prevailing culture within clients and business management at the time was the ‘WISKY’ mentality; “Why Isn’t Someone ‘Koding’ Yet”.That and the 6-month deadline led the team to cut corners on the preparation.  Some rudimentary ‘As-Is’ business process modeling had been done to identify where the sales process needed to be modified to include the regulatory requirements as well as where the new parts of the sales process needed to be inserted.The product Owner insisted that as much of the ‘As-Is’ had to be in the new system as well as the new parts.The team decided to go for the ‘low-hanging fruit’ approach, developing the easy and quick parts first; unfortunately, these did not include the regulatory requirements nor the new sales processes.After 2 months of development, the team released the first prototype to the client company to get feedback.  The client was very concerned that there was no sign of the regulatory requirements or new sales process and that the team had developed ‘As-Is’ processes that had been in the old system that were there because of the limitations of the old technology, such as overnight batch processing of data.It was at this point that the client was considering cancelling the development contract but they were 2 months closer to the important deadline so it was decided to bring someone in that could turn the ‘mess’ around; that someone was me.I started by investigating the Vision and establishing what was the minimum that was needed in the remaining 4 months.  It was decided that a system to support the end-to-end sales process of just one of the financial products, incorporating the regulatory requirements, without any of the new ‘bells and whistles’ would satisfy the regulators and the client company could continue trading.The ‘Product Owner’ was replaced with a less experienced salesman who was not as ‘wedded’ to the old sales process as the previous Product Owner.We established and prioritised the development objectives and put together a Business Plan that was used every week as a means to assess development progress toward the highest priority objective of getting the new regulatory requirements incorporated into the sales process.The new system was ‘finished’ one month early and was demonstrated to the regulators who had high praise and used the new system as a benchmark with which to assess the new systems of other companies in the same sector.During the month left before the deadline other high priority financial products were added to the system; the client deciding that they would suspend sales of the less important products until they too could be added to the new system.Lessons:1.The apparent lack of time always drives people to ‘cut corners’, especially in the preparation.  How many window and door frames have you seen that look ‘rough’ because the surfaces were not prepared adequately before applying the top coat of paint?  In this case study, some of the people were almost paranoid about the ‘New system in 6 months or die’ so that they focused entirely on the time aspect with little consideration about what the original Product Owner was asking them to do.As a consequence, the team produced a less than satisfactory first prototype.2. Don’t leave the requirements set to one person however experienced they are; the question of ‘do we really need to develop the whole of the new system in 6 months?’ would probably have been asked in the early stages if the requirements setting had been done by a group of people including some developers.3.The lack of prioritised development objectives and a Business Case to assess development progress toward the highest priority objective(s) aided the ‘low hanging fruit’ approach adopted by the outsource company enabling them to effectively waste most of the 2 months work in producing the first prototype.4.On a positive note, however, the incremental delivery nature of Agile had allowed the team to ‘fail fast’.  If the team had continued development without customer feedback for all of the 6 months, who knows what sort of system that they may have produced.Case Study 2:I was asked to do an Agile audit in an organisation because one of the senior managers was concerned that he was not seeing the benefits of ‘being’ Agile that were ‘sold’ to him by a chosen ‘partner’ development agency.The development was a programme of work to integrate 12 disparate systems, ‘inherited’ by the organisation by the acquisition of other organisations; the overall aim was to ensure consistency of data across the organisation and allow the use of a data warehouse for decision making.The programme was using an in-house Agile framework based on the DSDM framework. The anti-Agile practices across the programme that I discovered during the audit could make the definitive guide on how not to be Agile.However, I will confine my comments to the consequences of the lack of knowledge on building the Agile Business Case for just one of the projects.The project ‘Vision’ was to automate many business processes that were currently being done manually.  When I arrived, the project had been running, on and off, for about 18 months and had not delivered anything.  I asked what the project costs to date were and was told that they were in the order of £1 million but this could not be verified because cost accounting in the organisation and for the programme was very ad-hoc.The team was struggling with defining the details of some of the User Stories; several attempts had been made during several workshops to finalise these details before development in one or more Sprints.I decided to sit in on one of these workshops to see what was happening.A ‘Systems Analyst’ was sat in front of her laptop, not shared with the rest of the workshop, and asked questions of the business representatives.  They discussed their answers to the questions which mostly were preceded by ‘It depends’.  I asked if any prototypes had been attempted for the User Story under consideration and was told ‘we don’t do prototypes because we do not have any prototypers’.  I then asked the stupid question ‘What is a prototyper?’.  The obvious answer – someone who prototypes!  It became obvious that the organisation believed that prototypes had to be produced in code, rapidly.I went to the whiteboard, drew a large rectangle and asked the business representative what they expected to see on a screen, focusing on the most used path through the User Story.  In 20 minutes we established the ‘core’ data and business rules for the User Story; it had taken 3 months of sporadic workshops not to get that far.This workshop anecdote led me to ask how this ‘analysis paralysis’ situation had come about.  The answer was that the team had ignored one of the basic Agile framework ‘rules’ that development takes place in short, 2 to 3 week, Sprints; the aim of a Sprint is to develop, as fully as possible, a group of User Stories so that they are potentially shippable.  As part of the Sprint or Increment Reviews, the business should assess the Business Case to see if it remained viable.Apart from not running Sprints as recommended, the team had a less than adequate Vision and no Objectives on which to base a Business Case.  For some reason, which I was never able to fathom out, nobody in the programme or the rest of the organisation was questioning the lack of development progress for this project or the amount of money they were spending for no visible benefit.To cut a very long story short, when an adequate Vision and Objectives were created and a Business Case put together, the business realised that what they were trying to achieve was fundamentally flawed and the project was cancelled.Lessons1.Despite the poor workshop processes and abandonment of key Agile development practices, the fundamental problem with this project was a lack of adequate Vision and Objectives with which to construct a Business Case by which assessment could be made of development progress toward realising the expected benefits at a reasonable cost.2. When Vision, Objectives and Business Case were in place, the business realised the futility of the efforts so far and therefore had allowed a waste of £1 million by not having them earlier.ConclusionThese 2 case studies illustrate the worst cases of no Business Case that I have experienced; there are many others.Having tight deadlines or even no apparent deadline does not excuse the lack of sufficient and proper preparation.I discussed the Vision and Objectives issues in the first of this series of articles but these should be used to build a Business Case that can be used to assess development progress toward meeting the expected Objectives for a reasonable cost; developing User Stories is not the aim of Agile; the aim is to develop the right User Stories in the right order.
Rated 4.0/5 based on 21 customer reviews
How Not to be Agile –The Business Case 3559
  • by Steve Ash
  • 31st Aug, 2018
  • Last updated on 18th Jan, 2019
How Not to be Agile –The Business Case

Is Agile Everything?

‘How Not to be Agile’ may seem a strange title for the blogs mentioning about how good Agile is!

‘How Not to be Agile’ may seem a strange title for a series of articles about how good Agile is!  However, what I intend to do over this series of articles is to share with you the misinterpretations, omissions and mistakes that people make that significantly reduces the potential benefits for an organisation, or part of it, when it embarks on an Agile Transformation.

Agile Transformation is not easy!  Yes, the ‘mechanics’ of all the Agile frameworks are relatively straightforward to implement, given that people are trained adequately.  However, the root cause of just about all the problems that I have come across is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.

Last time, I discussed the potential pitfalls of not having a suitable and visible Vision and Objectives for whatever it is that we are trying to achieve, be it a new product, a major change to an existing product or the Agile transition itself.


This time, I will cover some of the omissions, misunderstandings and malpractices that I have come across with respect to the Business Case; an overall product development ‘document’ with which we can track whether the ongoing development is likely to meet the business value outlined or specifically stated in the development Objectives for a reasonable cost; it is no use developing a product for $1 million dollars if it will take 10 years of product use before it pays for itself.

I will start with a description of an Agile Business Case and then give examples of what has and could go wrong.

What is the Business Case?
 Business CaseHaving achieved an agreed Vision and Objectives, the business stakeholders and development team need to quantify the business value that is expected from the product, in what timescale, and the estimates of how much it will cost to develop so that that the business stakeholders can determine whether the development is justified from a business point of view.

These estimates are recorded in the Business Case; a cost-benefit analysis. In the past, in an effort to reduce development business risk as much as possible, some companies produced a detailed, task level, project plan with all the ‘who will do what and when’, factoring in known team member holidays etc.  By this means, they hoped to establish the probable costs of the development with a high degree of accuracy.  However, I have never seen the expected business benefits undergo such a rigorous analysis.

Also, I have never seen the Business Case updated periodically during the development so that it can be determined whether the development is still justifiable.

This way of producing a Business Plan usually involves a ‘development expert’ to do the technical estimations and takes a significant amount of time during which no business benefit is being accrued.

What is an Agile Business Case?
 Agile Business Case

“Therefore, ‘experts’ are asked for their opinion about probable or possible costs for different ways of solving the problem:

  • Develop the product from ‘scratch’ – usually the most expensive option
  • Use an existing product as a ’base’ and modify/configure it – the next most expensive option
  • Outsource the development – ‘passing risks to some other company’ – the costs can vary significantly depending on the contract type.

    From these ‘guesstimates’, the development Sponsor can take a decision as to which development option to take.  I will discuss Agile Roles in a later article.There is always another option for the Sponsor to take – ‘Do Nothing’; especially if the probable cost-benefit analysis indicates little Return-on-Investment.If the initial, ‘guesstimate’, Business Case cost-benefit analysis indicates that it may be worthwhile continuing with development,we can start gathering requirements.

solving problemsWhat is Agile Business Case Lifecycle?

Once the initial Agile Business Case has been created it is not ‘set in stone’; like most other things in an Agile environment, it is subject to change as we learn during the development. Indeed, I use a set of development ‘document’ templates, which includes an Agile Business Case, that all have ‘This is Subject to Change’ printed in red at the top and bottom of each page.

Post Product Backlog Creation

The Product Backlog, which I shall discuss in my next article, is a list of ‘requirements’ that have been ordered by business value and estimated.

These estimates, that have been done by the development team, can replace the costs section of the initial Business Case. The initial Business Case expected benefits can be assessed by a wider stakeholder population and either confirmed or modified.

The cost-benefit analysis for the modified Business Case values can be used to, again, assess whether it is advisable to continue the development, modify the Vision and Objectives to obtain a viable Business Case or cancel the development.

The time taken from establishing the Vision to achieving this first modified Agile Business Case should be no longer than 2 to 3 weeks; usually, a lot shorter time than is usually taken in a traditional product development environment.

At the End of Development Timeboxes

A Development Timebox is the short, 2 to 3 week period during which the development team completely develop a subset of the ‘requirements’ and what has been developed demonstrated to the relevant stakeholders.  Most of you will recognise this as the definition of a Sprint from Scrum; other Agile Frameworks use different names; I will use the term Sprint during the rest of this article because it is quicker to type!

It is recommended that the Agile Business Case be ‘reviewed’ at the end of each Sprint, during the Sprint Review, for the first few Sprints; it is during these first Sprints that the learning curve is steepest. The estimated costs against the actual costs can be assessed and the Agile Business Case updated if necessary.  Obviously, assessing the actual benefits accrued at this early stage in development is almost impossible.  However, a view can be taken on the new cost-benefit analysis as to whether to continue development.

Remember:

                                                                                                   ‘Fail Fast’
the simplest business planOnce the initial learning has been done, most organisations revert to reviewing the Agile Business Case during the Increment Reviews, done just before a group of functionalities is placed ‘live’; probably every 2 or 3 months.

Case Study 1:

Many years ago, I was asked to help a team who were building a financial products sales system to replace a company’s current system.  The ‘need’ that prompted this development was regulatory in that there had been ‘mis-selling’ of some of the financial products and the government had told the whole sector that they had 6 months ‘to clean up their act’.

The company’s current system was based on an ageing mainframe and it was decided that as well as trying to incorporate new regulatory business rules into the sales system, the whole process would be ‘transferred’ to a system using ‘modern’ technology so that additional sales processes could be incorporated, taking advantage of the capabilities of the new technology.

The company mitigated some of the huge risks that they were taking on by outsourcing the development on a fixed price basis; the outsource company decided that ‘Managed RAD’ (the precursor of Agile) was the way to go; I was helping the outsource supplier company team.

The ‘Vision’ was clear:

“To develop a financial products sales system that complies with Government regulation in 6 months so that the company can continue to sell financial products”

There was an onsite, senior salesman from the client company to give the requirements for the new system; the equivalent of a Scrum Product Owner.

Unfortunately, no one had taken the time to produce a Business Case; it was obvious wasn’t it? ‘New system in 6 months or die’!

The prevailing culture within clients and business management at the time was the ‘WISKY’ mentality; “Why Isn’t Someone ‘Koding’ Yet”.

That and the 6-month deadline led the team to cut corners on the preparation.  Some rudimentary ‘As-Is’ business process modeling had been done to identify where the sales process needed to be modified to include the regulatory requirements as well as where the new parts of the sales process needed to be inserted.

The product Owner insisted that as much of the ‘As-Is’ had to be in the new system as well as the new parts.

The team decided to go for the ‘low-hanging fruit’ approach, developing the easy and quick parts first; unfortunately, these did not include the regulatory requirements nor the new sales processes.

After 2 months of development, the team released the first prototype to the client company to get feedback.  The client was very concerned that there was no sign of the regulatory requirements or new sales process and that the team had developed ‘As-Is’ processes that had been in the old system that were there because of the limitations of the old technology, such as overnight batch processing of data.

It was at this point that the client was considering cancelling the development contract but they were 2 months closer to the important deadline so it was decided to bring someone in that could turn the ‘mess’ around; that someone was me.

I started by investigating the Vision and establishing what was the minimum that was needed in the remaining 4 months.  It was decided that a system to support the end-to-end sales process of just one of the financial products, incorporating the regulatory requirements, without any of the new ‘bells and whistles’ would satisfy the regulators and the client company could continue trading.

The ‘Product Owner’ was replaced with a less experienced salesman who was not as ‘wedded’ to the old sales process as the previous Product Owner.

We established and prioritised the development objectives and put together a Business Plan that was used every week as a means to assess development progress toward the highest priority objective of getting the new regulatory requirements incorporated into the sales process.

The new system was ‘finished’ one month early and was demonstrated to the regulators who had high praise and used the new system as a benchmark with which to assess the new systems of other companies in the same sector.

During the month left before the deadline other high priority financial products were added to the system; the client deciding that they would suspend sales of the less important products until they too could be added to the new system.

Lessons:

1.The apparent lack of time always drives people to ‘cut corners’, especially in the preparation.  How many window and door frames have you seen that look ‘rough’ because the surfaces were not prepared adequately before applying the top coat of paint?  In this case study, some of the people were almost paranoid about the ‘New system in 6 months or die’ so that they focused entirely on the time aspect with little consideration about what the original Product Owner was asking them to do.

As a consequence, the team produced a less than satisfactory first prototype.

2. Don’t leave the requirements set to one person however experienced they are; the question of ‘do we really need to develop the whole of the new system in 6 months?’ would probably have been asked in the early stages if the requirements setting had been done by a group of people including some developers.

3.The lack of prioritised development objectives and a Business Case to assess development progress toward the highest priority objective(s) aided the ‘low hanging fruit’ approach adopted by the outsource company enabling them to effectively waste most of the 2 months work in producing the first prototype.

4.On a positive note, however, the incremental delivery nature of Agile had allowed the team to ‘fail fast’.  If the team had continued development without customer feedback for all of the 6 months, who knows what sort of system that they may have produced.

Case Study 2:

I was asked to do an Agile audit in an organisation because one of the senior managers was concerned that he was not seeing the benefits of ‘being’ Agile that were ‘sold’ to him by a chosen ‘partner’ development agency.

The development was a programme of work to integrate 12 disparate systems, ‘inherited’ by the organisation by the acquisition of other organisations; the overall aim was to ensure consistency of data across the organisation and allow the use of a data warehouse for decision making.

The programme was using an in-house Agile framework based on the DSDM framework. The anti-Agile practices across the programme that I discovered during the audit could make the definitive guide on how not to be Agile.

However, I will confine my comments to the consequences of the lack of knowledge on building the Agile Business Case for just one of the projects.

The project ‘Vision’ was to automate many business processes that were currently being done manually.  When I arrived, the project had been running, on and off, for about 18 months and had not delivered anything.  I asked what the project costs to date were and was told that they were in the order of £1 million but this could not be verified because cost accounting in the organisation and for the programme was very ad-hoc.

The team was struggling with defining the details of some of the User Stories; several attempts had been made during several workshops to finalise these details before development in one or more Sprints.

I decided to sit in on one of these workshops to see what was happening.

A ‘Systems Analyst’ was sat in front of her laptop, not shared with the rest of the workshop, and asked questions of the business representatives.  They discussed their answers to the questions which mostly were preceded by ‘It depends’.  I asked if any prototypes had been attempted for the User Story under consideration and was told ‘we don’t do prototypes because we do not have any prototypers’.  I then asked the stupid question ‘What is a prototyper?’.  The obvious answer – someone who prototypes!  It became obvious that the organisation believed that prototypes had to be produced in code, rapidly.

I went to the whiteboard, drew a large rectangle and asked the business representative what they expected to see on a screen, focusing on the most used path through the User Story.  In 20 minutes we established the ‘core’ data and business rules for the User Story; it had taken 3 months of sporadic workshops not to get that far.

This workshop anecdote led me to ask how this ‘analysis paralysis’ situation had come about.  The answer was that the team had ignored one of the basic Agile framework ‘rules’ that development takes place in short, 2 to 3 week, Sprints; the aim of a Sprint is to develop, as fully as possible, a group of User Stories so that they are potentially shippable.  As part of the Sprint or Increment Reviews, the business should assess the Business Case to see if it remained viable.

Apart from not running Sprints as recommended, the team had a less than adequate Vision and no Objectives on which to base a Business Case.  For some reason, which I was never able to fathom out, nobody in the programme or the rest of the organisation was questioning the lack of development progress for this project or the amount of money they were spending for no visible benefit.

To cut a very long story short, when an adequate Vision and Objectives were created and a Business Case put together, the business realised that what they were trying to achieve was fundamentally flawed and the project was cancelled.

Lessons

1.Despite the poor workshop processes and abandonment of key Agile development practices, the fundamental problem with this project was a lack of adequate Vision and Objectives with which to construct a Business Case by which assessment could be made of development progress toward realising the expected benefits at a reasonable cost.

2. When Vision, Objectives and Business Case were in place, the business realised the futility of the efforts so far and therefore had allowed a waste of £1 million by not having them earlier.

Conclusion

These 2 case studies illustrate the worst cases of no Business Case that I have experienced; there are many others.

Having tight deadlines or even no apparent deadline does not excuse the lack of sufficient and proper preparation.

I discussed the Vision and Objectives issues in the first of this series of articles but these should be used to build a Business Case that can be used to assess development progress toward meeting the expected Objectives for a reasonable cost; developing User Stories is not the aim of Agile; the aim is to develop the right User Stories in the right order.

Steve

Steve Ash

Blog Author

Steve Ash has been working with ‘Agile’ since 1993 when it was known as ‘Managed RAD’.  He was an early adopter of the DSDM Framework in 1995 becoming a DSDM Board Member in 2002 and was a DSDM examiner.  He is a DSDM Advanced Practitioner and Accredited Trainer/Coach. Steve has since embraced Scrum, Kanban, the techniques advocated by XP, Lean Software Development and Lean Startup. He joined the Agile Alliance in 2002 and is a Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), SAFe® Certified Consultant (SPC4) and certified by APMG International to teach Agile Project Management and Agile Business Analysis courses. Since 1996, Steve has trained, mentored and coached hundreds of people in many public and commercial organisations in 11 countries from the USA, through Europe and India to Asia/PAC.
 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story.     This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story?   User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.  User stories typically follow a simple template as below. As a , I must be able to so that I can .  User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.  Writing user stories on an index card is actually the ‘Card’ part of the 3 C’s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type ‘Story’ as shown below.  The user story in the format listed above can be written in the summary field of the new issue creation screen.  User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn’t a test for it yet)   Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL — Visure Solutions (@VisureSolutions) 21 November 2017   JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words ‘Epic’ and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C’s in user stories that is ‘Confirmation’ is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria.   Gearset’s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets & keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm — Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the ‘Conversation’ component of user stories which is the 3rd C in the 3C’s.  Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner.    
Rated 4.0/5 based on 1 customer reviews
3538
Writing Effective User Stories in JIRA

User stories are one of the main methods of commun... Read More

Agile Scrum Roles And Responsibilities

Agile, Scrum, Waterfall, Kanban are different project management frameworks which are helping the companies to increase the productivity. These frameworks were created by the IT companies and especially web and application development companies because they needed a path but on which each and every employee can perform his daily tasks. However, out of these four frameworks, the Scrum is the most widely used framework in all the companies despite their nature of work. That is why in this article we are going to discuss the Scrum in detail to give you a better idea about this iterative framework which is making easier for the companies to complete their project. Scrum Objective: The basic objective of the Scrum is to keep the entire team on the same page throughout the project. The scrum framework allows the cross-functional work of the team of 4 to 10 members to provide the regular details and information sharing liberty so they can produce the best result. Scrum is a more like philosophical than the technical. It is a framework that can only be used as the guidance and there is no constant in it. All the success of the Scrum depends on the interactions among the stakeholders as it does the process. Scrum roles and responsibilities: The techniques of Scrum has become very popular and now considered to be the most important thing to do before starting any project. That is why the demand of the scrum masters and other professions related to the scrum has also increased, and people now are searching about the term scrum more. The scrum is a very specific and précised framework that is why it comprised on the following roles. Scrum Master Product Owner Scrum Team Stakeholders   Because the term Agile is often get associated with the project managers that is why many people believe that the Scrum Master is also a term for the project managers. However, the Scrum Master serves very different purposes than the project manager. The Scrum Master works as a facilitator rather than the authoritative person who is responsible for the project delivery. The Scrum Master is a coach, motivator and problem solver who can only assist the team by using all his experience of Scrum framework. According to many Scrum Masters, applying Scrum within an organization is not the actual scrum process. You have to make the organization to accept your new role and then change its culture which is the most difficult thing to do in any company. The prominent role of every Scrum Master should be to enhance the power of the team by committing them to the sprint goals without any interference from the management. Let’s discuss the major roles of all the above points separately. Scrum Master: The Scrum Master is considered to be the top-dog in every organization because companies usually hire them and don’t treat them as permanent employ that is why they are with no authority. It is their duty to remove all the hindrance or obstruction in the way of achieving any goal. It is also their role to enforce scrum ceremonies and processes. They are the ones who commit to goals and deadlines on behalf of the team. Product Owner: The product owner is responsible for conveying the vision of the stakeholders to the team. They have the authority to alter the scope. The Product Owners are responsible for the return on investment (ROI) that is why they occupy an authoritative position in the firm. Because they convey the vision of the stakeholders that is why they are the voice of the stakeholders. Not only with the team, but they also communicate with the stakeholders about progress and problems. Scrum Team: The Scrum Team is responsible for all the activities that lead them towards their sprint goals. They have to work with the Scrum Master to prioritize the items from the product backlog in the sprint planning. Once committed, it is their responsibility to fulfil the commitment and deliver the agreed results on time with great quality. The Scrum Master is not responsible for keeping his team organized that is they it is the duty of the Scrum Team to get self-organized. They have to be agile in the office and have to attend every standup and other ceremonies. They have to participate in all the meetings despite their nature and have to ensure that all the findings of the meetings are getting practically addressed in the project. Stakeholders: The Stakeholder has to keep a healthy relationship with the Product Owner in order to share every detail regarding his project. The Stakeholder is responsible for conveying his wishes and concerns to the product owner or else the product owner would not be responsible for his project quality and time duration. The Stakeholder has to provide regular input to queries from the Product Owner. Prioritizing the work affectively with the Product Owner is another job that the Stakeholder has to do to ensure his project development. Keep taking updates or keep giving updates regarding any change in the plans.
Rated 4.0/5 based on 1 customer reviews
9509
Agile Scrum Roles And Responsibilities

Agile, Scrum, Waterfall, Kanban are different proj... Read More

Best ways to implement Leading SAFe 4.5 in organizations

SAFe stands for Scaled Agile Framework. This framework is mostly used by the corporate bodies which need to scale from smaller organizations to larger ones. So SAFe is also known as an enterprise-scale development methodology. This framework was coined by Dean Leffingwell. It is an ‘information base’ which is freely available, and allows you to apply Lean-Agile practices at an organization level.   Scaled Agile Framework (SAFe) is referred as the Agile framework for software development. It renders an ease of operation for the development team. SAFe 4.5 is the most updated version introduced to match the needs of the organizations. This version consists of some new features as follows:  Fastest delivery with scalable DevOps and Continuous delivery  Quick testing using the Lean Startup cycle and User Experience (UX)  Improved Portfolio performance with Lean Portfolio Management (LPM) and Lean Budgets Additionally, SAFe 4.5 allows organizations to transform from the traditional approach to Lean-Agile methodology with the new Implementation Roadmap. Implementation Roadmap of SAFe 4.5 is a guide for the organizations. Reasons to switch to SAFe 4.5: ●  The updated version of SAFe 4.5 supports the range from simplest to the most critical development environment. SAFe 4.5 is able to mould according to the organizational needs. SAFe has four new   configurations as follows:  1. Essential SAFe - an initial phase which starts just after realizing the benefits. 2. Portfolio SAFe - adds portfolio level, strategy and investment funding, guidance on Agile programs, and Lean governance as a scenario. 3. Large Solution SAFe - for building large systems that involve Agile Release Trains and Suppliers 4. Full SAFe - for the largest firms those are seeking the benefits of the Lean-Agile enterprise.   ● SAFe 4.5 works by integrating Lean Startup Cycle and Lean UX, which creates an environment to form Minimum Viable Product (MVP). It fosters quick innovation. ● SAFe 4.5 has concentrated on the feature of rapid delivery using the techniques like Scalable DevOps and Continuous Delivery Pipeline. ● SAFe 4.5 has provided a guide in the form of a 12 article series, given a name as ‘SAFe Implementation Roadmap’. Based on the Change Management technique in the organization, the roadmap       guides on the critical steps that an organization can take to achieve long term goals.  ●  SAFe 4.5 is completely backward compatible. In SAFe 4.5, you just need to adopt the advanced principles, keeping old versions in place.                                                                                                  How is SAFe 4.5 Implemented? SAFe Implementation Roadmap provides guidance to the organizations in the form of a twelve-article series which describes effective strategies and a set of activities to implement SAFe at an organizational level. Let me illustrate the 12-article series below-   Reaching the tipping point.  Train Lean-Agile change agents  Train Executives, Managers and Leaders  Create a Lean-Agile Centre of Excellence  Identify Value streams and ART’s  Create the Implementation plan  Prepare for ART Launch   Train Teams and Launch ART   Coach ART Execution   Launch More ARTs and Value Streams  Extend to the Portfolio   Sustain and Improve SAFe is a pivotal framework as it helps to achieve business benefits at an organizational level. In order to understand the outcomes of Leading SAFe implementation, organizations must embrace and understand the Lean-Agile principles. Based on the Change Management strategies in the organization, the SAFe Implementation Roadmap guides on the critical steps that an organization can follow to achieve long term goals.   
Rated 4.0/5 based on 20 customer reviews
6347
Best ways to implement Leading SAFe 4.5 in organiz...

SAFe stands for Scaled Agile Framework. This frame... Read More