Search

Agile Filter

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.

How Not to be Agile –The Business Case

4379
  • by Steve Ash
  • 31st Aug, 2018
  • Last updated on 11th Mar, 2021
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

The Ultimate Guide to Sprint Planning

The Scrum framework has been popular lately and several studies have provedthat the global share of Scrum is more than 50%. One of the reasons for the phenomenal success of Scrum lies in its ceremonies, one of its key pillars.  Scrum has three critical components that create the structure or a skeleton and provides a way of working to the teams and individual, namely, roles, artifacts, and ceremonies. Scrum has four different ceremonies to support Agile software delivery where the Sprint starts with planning and ends with the retrospective. Let us quickly talk about the four ceremonies and then we will start with our topic of the day and deep dive more into Sprint planning. Daily Scrum The event is intended to bring together everyone in the scrum team and talk about what the accomplished last, what is the plan for today and is there any impediment. This event can be categorized under daily planning and collaborative team effort to attain the scrum goal. Sprint planning This event occurs at the start of the Sprint where the team together decides on the Sprint backlog and gains consensus on the sprint goal. They also talk about the estimation, capacity, risk, dependencies, and the timeline. This event is facilitated by the scrum master and occurs once in every Sprint. Sprint review This is the second last event in the print where the team showcases the entire deliverable they have been working throughout this print. This is the time when the stakeholders look at the finished product and provide their feedback. The event provides an effective platform for a collaborative approach with the client towards software delivery. Sprint retrospective This is one of my favorite events in Scrum, though the ceremony looks simple, if done correctly, it can yield tremendous results. It provides the team with a chance to pause and check which things are working, what is not, and how can they improve moving forward. Scrum ceremoniesEach of the ceremonies can be elaborated more as they are deep and dense. This article serves as an in-depthguide on Sprint planning for Scrum practitioners. The Sprint Planning meeting The What Sprint planning can be thought of as a ‘green flag’ that gives a go-ahead to the train called “Sprint”. The purpose of this meeting is to provide the sprint goal and ‘how’ that can be delivered. This is the first meeting that takes place in a Sprint where the scrum team comes together to create the Sprint backlog within a “time-box”, this time-box depends on the iteration length, if the iteration is of two weeks, the time-box can be up to four hours for a team of seven to nine people.  During the Sprint planning meeting, the product owner describes the objective of the sprint and what product backlog items can be utilized to reach that objective. Consequently, the scrum team decides how to work on ‘how’ to get the goal achieved. The How The sprint planning meeting is divided into two parts, first part, constitutes discussion on the sprint backlog creation and the second part revolves around the capacity and estimation. The product owner must keep the product backlog stays in a healthy state, it is prioritized and has the right requirements for the team to work on. The team should also be aware of their capacity and velocity to make appropriate Sprint commitment. Spring Planning meeting agendaThe Who The spring planning meeting is attended by the product owner, the development team, and the scrum master. All three roles are mandatory to run this meeting.  The product owner defines the objective of the sprint and supports the development team with the product backlog. In turn, the development team talks about ‘how’ to deliver and the approach they could take. They can also inform the product owner if the requirement is not doable (at times, the requirements might not be technologically feasible, in such cases the team can discuss the same with the product owner). The Scrum Master takes up the facilitation of the event, they make sure the team sits with an effective ‘input’ and comes out with an efficient ‘output’. The Inputs The Product Backlog serves as the ‘Input’ for the Sprint Planning meeting. It provides the development team with the starting point as it contains the list of requirements for delivery. The Product Backlog is owned by the product owner and hence the responsibility of keeping it up-to-date falls within their purview. The team starts with the highest priority item in the list, clear doubts (if any) and add it up to the Sprint Backlog. To make proper sprint commitment, the team should know their capacity and velocity. The Outputs The sprint planning meeting intends to generate a sprint goal and backlog. The output also defines the ’how’ approach, which the team will take to reach its goal. The team must understand the value of this event, as this draws a path for sprint success. The Scrum Master can help the team and the product owner to come up with an effective plan through their facilitation skills.Input and output of the Sprint Planning MeetingHow do we prepare for the sprint planning meeting? As with other events, the sprint planning meeting has a set agenda and timebox which the team must follow diligently. A healthy backlog is a key to efficacious sprint planning, which means, the Product Owner always must maintain and keep the backlog updated. The team needs to be aware of the available capacity and the targeted velocity this helps in coming up with the correct commitment during the Sprint planning session. What is a backlog? A backlog is a list of requirements from the client to create the desired product. It contains new features, enhancements, bugs, Infrastructure changes, or any architectural requirement. Any work that is related to a product should be in the backlog.  Backlog items are placed in a prioritized list manner Every item in the backlog has an estimate it can either be a high-level estimate or the exact/close estimate, depending on where it falls in the list. Usually, the top few items in the bucket have more clarity, details, and close estimates as compared to the items down in the list. Determining velocity Velocity is unique for every team; no two teams can have the same velocity. Every organization has a different approach towards velocity, ideally, the teams should take an average of the last five sprints. The average formula works for the teams who have been in the system for long or they have spent at least eight to ten sprints as a team.  Usually, velocity-based planning is done with mature teams who are aware of the product and they are good at process. With new teams, the ideal approach relies on the completed stories vs accepted stories ratio. Determining capacity Capacity is determined by available working hours in the sprint timeline which also takes into consideration, the leaves, any holidays, and contingency hours (if required). Capacity directly impacts the output as a team and helps them during Sprint commitment.  Sprint Planning checklist While Agile development is more of a mindset than a methodology, checklists can help guidetheproduct owner, the development team, and the scrum master as they plan and execute sprints. Sprint planning preparation A few days out from the actual sprint planning meeting: Review product roadmap and vision.  Ask team members to update boards and focus on moving tickets to done.  Run sprint review and retrospective.  Groom product backlog: Make sure every user story has a clear priority, is fully formed, and up to date with context and estimates.  Choose sprint goal.  Create a sprint backlog of enough user stories to fill two sprints. Sprint planning meeting Ensure your entire team is present for the meeting.  Start video call for remote team members.  If needed, clean up old board(s) with team by checking status of open tickets.  Discuss spillovers: Should these be continued or dropped? Move any spill-over tasks into the right buckets.  Set the stage with product and market updates.  Define the sprint goal.  Create a “new sprint”. Discuss the goal and team’s capacity:  Is this realistic? If not, can the team lower the scope?  Worst case scenario the product owner needs to come up with a new sprint goal. A few days out from the actual sprint planning meeting: Discuss proposed sprint backlog: Let the team pick user stories and tasks that match the sprint goal and capacity.  Discuss the definition of “done”.  Break down each user story into individual tasks: Make sure each task has as much information as possible.  Ask whether the scope of work leaves time for unexpected issues.  Ask if the scope of work leaves space to tackle bugs and technical debt.  Move sprint backlog of decided-upon user stories and associated tasks into the sprint board.  Get verbal confirmation from the team that they know what to do.  Set up due dates and times for future scrum meetings.Here is a quick checklist to help you plan the Sprint Plan. You can modify and adapt as necessary.The outcome of the Sprint Planning meeting The planning meeting intends to come up with Sprint goal and sprint commitment which is in the form of Sprint backlog. This backlog contains a list of stories, bugs, enhancements, etc. as required by the product owner. The output of the Sprint planning meeting is also to define the approach, the task, and other activities required to achieve the Sprint goal.  Everything that needs to be done is part of the Sprint backlog, by the end of Sprint planning meeting the team should have a solid plan with the ownership This output is further shared with the stakeholders, management and within the team which not only helps in being transparent but it also supports the team to stay focused. How to get Sprint Planning right Scrum focuses on time boxing and hence Sprint planning also requires control over the time limit for the event. As per the industry standards, a sprint of two weeks should be time-boxed for a maximum of 4 hours. The scrum master is responsible for making sure the team sticks to the timing and helps them in coming up with the plan. Spend planning can be an exhaustive ceremony where the team brainstorms, discusses the requirements and ownership.  With great facilitation skills, the scrum master can ask the team to start with an item they know well and subsequently move forward. The team can utilize various estimation techniques to define a number or a story point for each requirement. They can use T-shirt sizing, poker planning, or any other technique they are comfortable with. For effective estimation, the team needs an environment that is transparent, trustworthy, and open to new ideas. This reminds us of the Scrum values and principles that form the foundation of the framework. Common reasons why Sprint Planning fails Multiple reasons can contribute to scrum planning failure. Let us look at some of the frequent cases: Uncooked backlog Most of the time the product backlog is not up to date and lacks prioritization. In such cases the team struggles in defining the Sprint goal, they face difficulties in defining the Sprint commitment due to lack of clarity and details. Unrealistic expectations Oftentimes teams are required to work on requirements that are not feasible, or the team faces some technological challenge. Over-commitment When the teams do not realize the capacity and their velocity and tend to over-commit, this leads to hurdles in delivery. Beyond Time-box Spending too much time in Sprint planning can also jeopardize the event, the team must follow the time-box, going over minute details is not required. Scrum is an empirical process, which means You do not have to plan everything upfront.   Quick tips for success Set a Goal The Product Owner should come up with a sprint goal and share it with the development team. The goal helps the team and staying focused throughout the sprint, they can also use baby scrum meeting to check if they are on track with the goal. Healthy product backlog If the product backlog is in the Good shape, and has stories in order of priority, the team can start pulling from the top. they can even plan a pre-planning meeting, which is also known as backlog grooming who defines the upcoming sprint backlog. Valuable meeting measures Everyone in the team should have the sprint planning meeting invite and if required it should contain the link to video conferencing in-case of a distributed team. The team should have the data on capacity and velocity, and they understand estimations and prioritization. They can use different colored stickies to represent backlog items for example stories can be represented with green and bugs can be presented with red. As per the discipline, the team should follow timeboxing strictly, they can finish early but to go beyond the time is not recommended.  Best practices in Sprint Planning To course a positive sprint, you need to be very prepared and have a solid understanding of what is practicable to shape with the team you have within the timebox. This is the reason why a sprint planning session is so vital for placing the foundation for an agile development project. Let us touch base on some best practices that the teams can adopt for the smooth running of the scrum event. Strategy for uncertainties During the sprint planning meeting, the team talks about capacity, velocity, and shapes their Sprint commitment around the confident items. Planning for uncertainties not only helps in contingency but it also reduces the upcoming risk that can pose an impediment for the team. Sprint skeleton Laying out the stories or Sprint items in the form of a map helps the team in getting a tentative idea around each deliverable. this also helps in defining the internal dependencies and the teams can better plan by moving them up and down. Building consensus It is important to get the team onboarded together as a single group for the sprint goal. They should understand the importance and the urgency of the deliverable and they are ready to take the ownership, this also requires supporting the teammates. Benefits of Sprint Planning A successful Sprint planning creates a smooth runway for the team to start their work. It provides clarity in terms of commitment, goals, timelines, and ownership. The output of the Sprint planning meeting sets an expectation with both the parties - the scrum team and the stakeholders - on what to expect by the end of the Sprint. It can be visualized as the team pulling a bucket of work from a big pile and focus on delivering that bucket with expected quality. Ready, set, sprint! “A goal without a plan is just a wish.” - French writer and pioneering aviator, Antoine de Saint-Exupéry Done in the right spirit, Sprint planning can do wonders in sprint delivery. All it requires is a focused approach, discipline, few best practices, and a collaborative approach towards a solution.  If you have followed this guide, at the end of your sprint planning session you and your entire team should walk away with: An agreed-upon Sprint Goal and a clear definition of “done” Commitment to a realistic sprint backlog Understanding of the bug fixes and support work included in the backlog Detailed tasks for each user story with an estimation and acceptance criteria Due dates and scheduled scrum meetings Now, all you have to do is the work.Ready to start or grow your Agile career?  Check out our latest courses, learn the skills and get the personalized guidance you need. 
6891
The Ultimate Guide to Sprint Planning

The Scrum framework has been popular lately and se... Read More

6 Metaphors To Understand The Value Of Scrum Values

The Scrum framework, a team-based approach, follows certain rules and principles helping the organizations and professionals both to identify ‘what works best for them’. The commitment, focus, openness, respect, courage are the five core Scrum values which are often underrated. These values add ethics to Scrum project management encouraging the members to follow a defined route for project management; therefore, the understanding of these values is very important for Scrum team members.  The following six metaphors simplify the understanding of Scrum values:  1. Scrum Values Are Like "Fasteners" The fasteners are used to bind two materials, similar or different, together and resist their separation. The Scrum values serve a similar purpose by keeping the Scrum team members together despite their different roles. Scrum team members need to practice all the Scrum Values as the parts of a unit for performing up to the full potential, whether the results are as per expectations or not.    2. Scrum Values Are Like the "Foundation" The Scrum values provide a stable foundation for sustainable project development. The foundation is built on the confidence and trust of members over each other. In a well developed Scrum team, members believe in the capabilities of other members; and, it helps them to handle the challenges collectively in a planned manner. The strong foundation encourages delivering the best for each Sprint goal. The strong relationship and mutual understanding help the Scrum team perform as a unit for the common objective – profitable on-the-time delivery of best-quality project.          3. Scrum Values Are Like a "Compass" A number of times, a Scrum team struggles hard to hit the Sprint goals despite having required skills, resources, support and opportunities. Without having a clear vision, team members feel perished. A great vision always precedes the success; but just having a vision is not enough until you understand it in the light of your mission. Therefore, it is important to check the vision whether it is compelling all the team members to deliver their best or not.  Scrum values are the compass-like guiding tool. Scrum team members embracing the Scrum values possess the moral compass that drives them towards the Sprint goal, helps them stay together, and guides to choose the right process. The Scrum values guide the Scrum team like a compass to go ahead for a successful project delivery.  4. Scrum Values Are Like a "Magnet" The ‘Law of Magnetism’ mentioned in ‘The 21 Irrefutable Laws of Leadership (John C. Maxwell, 1998) states that “Who you are is who you attract.” The practicing of Scrum values develops a positive energy helping you to develop an effective Scrum team and to keep all the members intact. The attitude to follow the Scrum values strictly instils the feel of unity among the team members; and, this magnetic force improves the project quality and individuals’ performance.       5. Scrum Values Are Like The “Sportsmanship” The metaphor “sportsmanship” to define Scrum values brings the notion to compete. It drives the Scrum team members to manage the complexities, challenges of shorter sprint duration, new guidelines, backlog work pressure etc. Like the sportsmanship keeps the sportsman cool despite the tough competition on the track, the Scrum values  encourage the members to focus on the targets without being perturbed by the new developments.      6. Scrum Values Are the "Identity"  The defined Scrum Values are the identity of a Scrum team because these values guide the team members on ‘how to behave and act’ securing the organization’s interests while satisfying the customer as well. Your beliefs as a team member identify you because these beliefs govern your thought line and actions. The management expert Ken Blanchard says that organizations claim for having a set of behavioural values but these values are the commonly accepted generic organizational beliefs pertaining to profitability, responsiveness to customers and integrity. Scrum values guide the members’ behaviour in the line of organization's vision & mission.    The word "commitment" is a #Scrum value, but was removed from the Scrum Guide several years ago in relation to the team's Sprint Goal. Why? Because committing to behaviour is effective, whereas committing to achieving x output in a fixed timeframe isn't. — Neil Killick (@neil_killick) March 13, 2018 Conclusion:    Scrum framework guides to imply a team-based approach ensuring the maximum values to the customer and business. After the successful development of Scrum team, the next task of Scrum master is to get the best from each member; and, it is possible only if each member understands the importance of Scrum values and respects them as an organizational culture. Organizing the ‘Scrum certification training’ for the concerned team members helps a lot to get the best from the individuals through the smooth processes, ensuring the peak deliverance at project completion.
6 Metaphors To Understand The Value Of Scrum Value...

The Scrum framework, a team-based approach, follow... Read More

INFOGRAPHIC: SCRUM Process In A Nutshell

We provide Certified Scrum Master training, to check out the schedule click here
INFOGRAPHIC: SCRUM Process In A Nutshell

We provide Certified Scrum Master training, t... Read More

Useful links