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

4531
  • 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

What is the Cost of Top Scrum Certifications in 2021?

Over the past few years, the job market has witnessed an exponential growth in the demand for Scrum Master professionals.  LinkedIN listed Scrum Master as among the top 10 most promising careers in 2019. Two years on, the popularity for Scrum and Agile related roles is at an all-time high.  Getting a certification to demonstrate your capabilities will help you reach milestones in your Scrum Master career. As a certified professional, you can increase your employability, rise up the career ladder and earn high remunerations.There are a number of Scrum Master certifications available from world renowned accreditation bodies. These certifications are accepted all over the world and give you the unique benefits associated with holding an acclaimed credential.As a certified Scrum Master, you will be able to:Validate your commitment to continued excellence and quality in Scrum,  Demonstrate proficiency in Scrum values, principles, and tools,Advance your career in Scrum with confidence,  Stand out at interviews and leverage on career growth opportunities,  Earn higher than experienced non-certified peers,Become part of the global Scrum and Agile community,Network with industry leaders and Scrum professionals, and  Advance your Scrum journey with each certification.To help you understand the Scrum Master certification cost and other details, we bring you a compilation of the most popular Scrum Master certifications that are available.The following table lists different certifications with their cost and renewal cost.Sr. No.CertificationScrum Master certification CostRenewal Cost1.CSM2-day CSM training cost: INR 24999 in India, USD 1295 in US and CAD 1495 in Canada, includes examination feeRetake at no cost for the first 2 attempts within 90 days after you receive your welcome email.  You will be charged a minimum of $25 each from the third attempt or after completing 90 days post training.$100 and 20 SEUs, every two years2.PSMTraining cost: INR 25999 in India, USD 1299 in US and CAD 1899 in Canada, includes examination fee$150, if opting for the examination without trainingNot required, has lifetime validity.3.SAFe® Scrum MasterTraining cost: INR 55999 in India, USD 1099 in US and CAD 1395 in Canada. Includes examination fee.Each retake after the first attempt costs $50.Not required, has lifetime validity.4.A-CSMTraining cost: INR 41999 in India, USD 1299 in US and CAD 1499 in Canada. Includes certification fee.$175 and 30 SEUs, every two years5.Disciplined Agile Scrum Master (DASM)Training costs will be updated shortlyCourse fee covers one exam attemptRetake costs US$150.$50 USD annual renewal fee and 7 hours of professional development (minimum 5 Disciplined Agile hours) are required each year for maintaining the credential6.Scrum Inc. Scrum Master™ CertificationTraining costs will be updated shortly$100, every year.Read along to know more on the Scrum Master certifications listed above in the table. The main objective of the same is to provide you with an in-depth knowledge of the various Scrum Master Certification costs as well as their renewal costs.1. Certified ScrumMaster® (CSM®)Certified ScrumMaster (CSM) is the most widely acknowledged Scrum Master certification. This entry level credential is a great way to start and maintain your career in Scrum. To gain the Certified ScrumMaster (CSM) certification, you will be required to attend a 2-day classroom training, following which you will have to take an online test.Certified ScrumMaster Certification CostDepending on where you choose to get your training from, the 2-day Certified ScrumMaster (CSM) course costs around $1295. This cost covers the following:A 2-day instructor led live training / 16-hour instructor-led online courseFirst two years of certification  Two attempts to take the exam (within 90 days of attending the course)  Course materials will be provided by the instructor in the class  Two-year membership to the Scrum Alliance communityCertified ScrumMaster (CSM) Renewal costEvery two years, you need to renew your CSM credentials by paying a renewal fee of $100 and earning 20 Scrum Educational Units (SEUs). This renewal fee includes the Scrum Alliance membership fee, which has a validity of two years.CertificationCost of CertificationRenewal CostCSM2-day Certified ScrumMaster (CSM) course costs around $1295 (costs can vary) depending on the region you train from$100 and 20 SEUs, every two years2. Professional Scrum Master™ (PSM)Offered by Scrum.org, Professional Scrum Master™ certification is highly sought after by Scrum Masters who want to lead more efficient and effective teams. This 2-day course covers the principles and processes of the Scrum framework, and helps aspirants understand the advanced thinking behind servant leadership and empiricism. The Professional Scrum Master™ assessment is available for anyone who wishes to exhibit their fundamental level of Scrum mastery.Professional Scrum Master™ Certification CostIf you feel that you have good knowledge of Scrum, understand the Scrum Guide and know how to apply Scrum within Scrum Teams, then taking the course is optional. You can take the PSM I assessment directly, which costs $150 per attempt.But if you choose to attend the 2-day training, then the exam fee will be included in the course fee, which costs around $1299, depending on the training provider. You’ll have two attempts to clear the exam if you choose to attend the training, as opposed to the one chance that you will get when attempting the exam without any training.Professional Scrum Master™ Renewal CostCertifications provided by Scrum.org hold a lifetime validity. Hence, PSM certification does not require any additional payment or renewal.CertificationCost of CertificationRenewal CostPSM$1299, depending on the training provider$150, if opting for the examinationNot required, has lifetime validity.3. SAFe® Scrum MasterSAFe ®  is a framework that helps scale agile to the enterprise. The SAFe® Scrum Master credential is a validation of the holder’s ability to be an effective Scrum Master in the SAFe environment. By attending the 2-day course, you can master the responsibilities of a Scrum Master in a SAFe® environment, learn ways to execute the Program Increment successfully and learn proven approaches to become a servant leader and coach in order to build high performing Agile teams.The SAFe® Scrum Master certification is accredited by Scaled Agile, Inc.SAFe® Scrum Master Certification CostThe course registration fee includes the first attempt of the exam, provided the exam is taken within 30 days of completion of the course, after which each retake attempt costs $50.The certification costs around $1099, which includes the mandatory course fee as well.SAFe® Scrum Master Renewal CostSAFe® certifications are valid for one year. After completion of the first year, you will have to get your certification renewed by paying a renewal fee of $100.CertificationCost of CertificationRenewal CostSAFe® Scrum Master$1099, depending on the region you train fromEach retake after the first attempt costs $50.Not required, has lifetime validity.4. A-CSMThe Advanced Certified ScrumMaster℠ (A-CSM℠), is the next step after the CSM in your evolution as a Scrum Master. While the CSM is a great entry level certificate, the A-CSM is an advanced level credential that displays your proficiency in scaling Scrum, coaching Agile teams and being an exceptional Scrum Master/servant leader.A-CSM Certification CostThe A-CSM workshop fee which includes your certification fee costs around $1099 and includes:2 Days Live Instructor-Led Online Training16 PDUs and 16 SEUs2-year Scrum Alliance MembershipYou have to attend a 2-day workshop conducted by a Scrum Alliance REP or Certified Scrum Trainer and complete all the learning objectives in order to gain the A-CSM credential.A-CSM Renewal costsEvery two years, you are required to log in 30 SEUs and pay a renewal fee of $175 to keep your certification in good standing.CertificationCost of CertificationRenewal CostA-CSM2-day A-CSM course costs around $1299 depending on the region you train from$175 and 30 SEUs, every two years5. Disciplined Agile Scrum Master (DASM)Offered by the globally recognized PMI®, the DASM is a perfect certification for those who want to be efficient Scrum Masters, improve processes and drive results with the help of the Disciplined Agile toolkit. Ensure business outcomes and gain a reputation in your organization by successfully meeting goals and bringing together enterprise architecture, portfolio management, vendor management and finance together.DASM Certification CostThe course fee for DASM certification includes the exam fee. Your training should be conducted by an Authorized Training Partner (ATP) of PMI®.DASM Renewal costTo keep your DASM credential active, you are required to pay the annual renewal fee of $50 and log in a minimum of 7 PDUs.CertificationCost of CertificationRenewal CostDisciplined Agile Scrum Master (DASM)Training fee will be updated shortly$50 USD annual renewal fee and 7 hours of professional development (minimum 5 Disciplined Agile hours) are required each year for maintaining the credential6. Scrum Inc. Scrum Master™ CertificationThis course and subsequent credential approved by Dr. Jeff Sutherland, the co-creator of Scrum and inventor of Scrum@Scale, is among the most respected credentials in the Scrum world. It helps you understand Scrum principles, techniques and processes of creating high performing teams and make a mark for yourself in your team and organization as an exceptional Scrum Master.Scrum Inc. Scrum Master™ Certification CostThe designation is offered by Scrum Inc.™ to practitioners who successfully complete training by an authorized training provider and demonstrate their understanding by passing the exam. The training fee includes the cost of the examination, and training material approved by Dr. Jeff Sutherland. Participants need to successfully complete the course and pass the exam to gain the credential.Scrum Inc. Scrum Master™ Certification Renewal CostCredential holders must renew their Scrum Inc. Scrum Master™ certificate annually within one month from the expiration date. The renewal fee for Scrum Inc. Scrum Master™ certification costs $100 (USD).CertificationCost of CertificationRenewal CostScrum Inc. Scrum Master™ CertificationTraining fee will be updated shortly  $100, every year.What’s Your Next Step?In this article, we’ve introduced you to the most popular Scrum certifications in the industry, and compared the costs of getting certified as a Scrum Master to help you make an informed decision.  While the cost certainly is an important consideration, you should also keep in mind your primary objectives for getting certified before you make your choice. Which is the certification that will add value to your resume and help to take your career places? Or, which is the certification that is most prized by your organization? What are the skills that you’re looking to gain, and what outcomes do you hope to accomplish?  Choose wisely, and take the right steps in your Scrum Master journey!
10065
What is the Cost of Top Scrum Certifications in 20...

Over the past few years, the job market has witnes... Read More

Top 21 Scrum Best Practices for Efficient Agile Workflow

Scrum, arguably the most popular Agile framework in use across industries, has been proven to help develop products in a timely and highly efficient manner. The 14th State of Agile Report states that 97% of organizations practice Agile development, out of which 58% prefer to use Scrum as their go-to method.And with good reason, too! Scrum lays out a series of simple principles and processes, which are very easy to follow and get measurable results. Not only does the frequency and velocity of product delivery increase, but changing requirements are also accommodated—an imperative in the current volatile market conditions where to be inflexible means to be left behind.In this article, we review the top Scrum best practices that streamline and optimise Agile workflows, creating stellar results.For those who are new to Agile and Scrum, let’s start with a brief introduction.Scrum in a nutshellScrum is a lightweight Agile framework that allows product development to be carried out in short and incremental iterations, through collaborative teamwork.During each iteration, called a Sprint, the delivery of a small increment of value is completed. Sprints are time-boxed, usually lasting two to four weeks, and allow the team to break down complex projects into short, doable tasks.As the team catches up on a daily basis, as well as at the end of every Sprint, work becomes transparent and obstacles, if any, are ironed out before they escalate out of control and hinder progress.  The project becomes more flexible and adapts to changes easily, as requirements are re-evaluated and task priorities are re-grouped at the end of every sprint.Scrum Roles and the Scrum TeamThere are three clearly defined roles in Scrum.  The Product Owner is the person who creates the Product vision, sets the direction for each sprint, and acts as the bridge between the team, customers and stakeholders. The PO maintains and manages the Product Backlog which determines the progress of the product development.The Scrum Master is the one who holds things together, helping the PO to define value, and communicating that value to the team so that they can deliver it. He or she creates and facilitates an environment that is conducive to Scrum success.The Scrum Team is a cross-functional, self-organising group of developers who are jointly responsible for product delivery. A team usually comprises not more than seven people, who are required to communicate and collaborate well together.  There is no hierarchy on a Scrum team, and the Scrum Master is considered their ‘servant leader’ and not their manager.Scrum Best PracticesWhether you’re a product owner, Scrum master or a team member, here is a set of best practices that can help to improve your efficiency and set you on the track to team success!Teamwork and meetings1. Create Product Backlog in conjunction with stakeholders.The stakeholders can contribute effectively to creating the product vision, and must be roped in for the inputs while creating the product backlog. During the negotiations on the backlog and while re-prioritising tasks, the team and stakeholders can come to a better understanding of the vision and what is expected to be delivered.2. Stakeholders must participate in Scrum meetings.When stakeholders and Product Owners participate in Scrum meetings, they will understand the workflow and the ways in which the team works. In turn, they can offer valuable feedback on the progress of work and about the deliverables during each sprint.3. Try not to regroup teams.When a team has worked together successfully on previous projects, they will already be sharing a rapport and understanding of each other’s capabilities. Rather than breaking the work rhythm, the best practice would be to keep productive teams together. This, of course, is not always possible as some projects will need regrouping due to different skill requirements.4. Work on team building.Team building is a practice that should never be neglected or sacrificed for want of time. A group that is cohesive will work better and faster, and the Scrum Master should use team-building techniques and activities to foster cooperation and collaboration.5. Don’t sit down during Stand-ups!.The reason why the daily meeting is called a Stand-up is because people are expected to stand up, and not sit down! Typically, meetings where everyone is standing up are shorter and get the expected results, while sit-down meetings tend to drag on and on.6. Nurture remote communication.When teams are distributed across geographies, or work-from-home mandates are in place, it’s important to set guidelines for remote communication. Important details could be missed out on calls, and critical notifications should be documented over a shared tracker so that they are flagged. Collaboration software makes it easy to set up notification messages to all the people concerned.Planning and estimates7. Keep stakeholder in the loop while estimating.It is always better that the principal stakeholder should be present during estimating meetings. If the team has any doubts, they can get cleared at once. What’s more, the stakeholder will understand the why, what and how behind estimation and this will help to establish trust and accountability.8. Plan a new sprint only when the backlog has enough items.Only when the product backlog has enough items for the next two sprints, is it time to plan the next one. Scope creep happens when there is uncontrolled growth in the scope of the project, because there was poorly defined scope for the next few sprints in the backlog.9. Set goals clearly.Unless the goals for each sprint are clearly laid out, it could become very difficult to prioritise the tasks in the backlog. The team and customers must align their objectives in order to set the goals that the team will achieve during each sprint. Based on the goals, the Product Owner in conjunction with the team will choose the tasks that must be completed during the sprint.10. Estimate using Planning Poker.Planning Poker is a proven, easy to use technique for estimating and planning. Using this simple technique, accurate and doable estimates can be achieved.11. Set time aside daily for risk mitigation.By planning a six hour day and leaving two hours aside each day for risk mitigation, it is possible not to fall short on time estimates. Many unexpected things could happen that turn timings awry, and by doing this it is possible to be prepared for unforeseen circumstances.12. Do not stretch or cut short sprint timings.The time frame for a sprint should not be stretched or curtailed, as otherwise the team will be tempted to neglect set timelines in the expectation that they will be reset. Even if a story is unexpectedly big and cannot be completed in a sprint, at the end of the agreed-upon timeframe the sprint should end, and the items that were not completed should be moved to the top of the backlog for the next sprint. At the same time, if the stories are completed ahead of time in a sprint, then some smaller stories could be added to help keep the schedules on track.Managing backlogs13. Keep sprint backlog separate from product backlog.The product backlog is updated regularly, while the sprint backlog is kept frozen and can be referred back to at any time. Do not mix up the two or combine them.14. Use task prioritisation techniques.Task prioritisation techniques such as MoSCoW, Business value approach, Kano model, Walking skeleton and so on can be used to prioritise tasks in the product backlog. Simple excel documents can list out backlog tasks and show the status and priority (must, could or should are most frequently used terms). Use the technique that makes best sense for your team, and that everyone is able to understand.15. Itemise user stories by assigning IDs.To cut through ambiguity, assign an ID to each user story so that the team knows exactly what is being discussed. Two user stories may sound similar but be different, and team members may think that a different story is being discussed.16. Map functional and technical dependencies.Dependencies could be functional (defined by stakeholders) or technical (defined by the engineering team). By mapping both types of dependencies, the workflow is smoothened and optimised, and bottlenecks can be identified and removed.17. Use a Scrum board.Many people work better when they have visual aids to guide them. A Scrum board is a very useful tool in this regard. The board is a visual representation of User stories, tasks that are yet to start, in progress and done. It can also indicate blocks, testing tasks and reviews from the Product Owner.  Tools like JIRA and Trello are very easy to use and understand, and offer great value to the team.Tracking and predicting18. Use sprint burndown charts.Burndown charts that visually depict the progress of the sprint are a great visualisation tool that detects issues when they appear, and helps to resolve them before they escalate. Completed tasks per day are mapped against the planned tasks, giving an indication if the progress goes off track.19. Use release burndown charts.Release burndown charts depict the sprints that are needed to complete, or release, the product. The team can decide whether they need to adjust the timeframe or not. Using these charts is a good practice to follow, especially if the product backlog was updated over the course of the project with new user requirements.20. Chart velocity.By calculating the velocity, the progress of work can be charted against initial estimates, and used to better predict team commitments and results. If the velocity is changing a great deal, then the sprint planning must be revisited and made more reliable.21. Invest in good quality software.Tools that are built for Agile teams can help with project planning, time tracking and measurement of metrics. JIRA, Toggl, Git, and Slack are popular tools that are very supportive and can help to streamline and optimise workflows.To sum up…Implementing a smooth, streamlined Agile workflow could take a lot of planning and strategizing, but with the right mindset, approach and collaborative tools, it doesn’t have to be difficult!  Each team is different, and you might need to experiment with a few approaches and Scrum best practices till you find the one that’s right for you.After all, the main premise of Agile is that you should be flexible, and adapt when the need arises!
10990
Top 21 Scrum Best Practices for Efficient Agile Wo...

Scrum, arguably the most popular Agile framework i... Read More

Product Owner vs Scrum Master: Key Differences

Scrum Master vs Product Owner: The two most important roles in a Scrum team. Though they seem similar, there are significant differences between the two. The pandemic has accelerated your organization’s need to go agile. But in your quest for digital transformation which roles will you hire for? The Scrum Master vs Product Owner has been a long standing debate, despite the fact that both are indispensable roles in the Scrum software development methodology and play their part in Agile transformations. Let’s look at these two roles, their specialities, differences and contributions to the digital landscape. Who is a Scrum Master? “The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.”—Scrum.org Who is a Product Owner? “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner”—Scrum.org Scrum Master vs Product Owner The Scrum Master and Product Owner are different roles with different responsibilities, yet they complement each other. The Scrum master should support the Product Owner in every step possible.   There should be an amicable relationship between the Product Owner and the Scrum master. Disputes may arise between the two, if the roles are not clarified. The Scrum Master’s main aim is to ensure project success, by assisting the product owner and the team in using the right process and adhering to Agile principles. Scrum Master Product Owner Servant leadership: The day to day activity of a Scrum Master involves servant leadership where they are involved in performance planning, coaching, self- organization, removing obstacles, resolving conflicts and serving the team. Stakeholder satisfaction: The first responsibility of the product owner is customer satisfaction and this they carry out by ensuring that customer requirements are given priority and there is transparency between development team and stakeholders.   The product owner guarantees stakeholder satisfaction by ensuring product success, and building a product which meets business requirements.   Coach and teacher:  Agile coaching is a Scrum Master’s primary skill. Teaching Scrum skills, especially to new Scrum teams is a huge part of the Scrum Master’s responsibility.   They need to ensure that the team is working as per Scrum and Agile principles and following processes. Conflict resolver: Product owners may often come across unreasonable or difficult to handle stakeholders.   Having conflict resolution skills will come in handy to diffuse any untoward situations or escalations that may arise with stakeholders or development team members.     Technical familiarity:  There is no doubt that having some technical competence will help a Scrum Master be better at the job.   Technical acumen will help a Scrum Master remove any impediments the team faces and build better products by providing the correct tools and techniques. Collaborator: A product owner is a great storyteller, which means that they are able to explain the vision of the product to the developers.   They need not necessarily have the technical skills to prepare user stories but they can effectively collaborate with those who can.     Organizational skills:   As someone who leads and guides the Scrum team, having good organizational skills is a must-have in a Scrum Master’s repertoire.   SMs must ensure that work is allocated correctly, there is no slippage of tasks and deadlines are met.   Prioritization skills: The Product Owner must have inherent prioritization skills in order to prioritise items on the backlog. Soft Skills: A Scrum Master should have great interpersonal skills, should be a conflict manager with the ability to solve internal and external conflicts, should be an excellent communicator and must have empathy towards team members. Soft Skills:  Good communication skills and being business savvy are paramount to being successful as a Product Owner.   Having to work with stakeholders and other parties means that Product Owners must be able to communicate the status of the product and other technical knowledge that the customer may wish to know.   Similarly, they must be able to communicate to the team about the vision of the product and stakeholder expectations.   Scrum knowledge: What is a Scrum Master without Scrum knowledge? The primary responsibility of the Scrum Master is to guide the development team on all things Scrum and make sure that the development of the product is taking place according to Scrum and Agile principles and values.   This will ensure that all benefits that are associated with Scrum and Agile are realised during the course of the project.   Scrum knowledge: The product owner must have knowledge of the product roadmap, release management, product backlog management, sprint planning, review and retrospectives, in order to maximise product value. Scrum Master vs Product Owner – A Responsibility Comparison Scrum Master Product Owner Aiding the team: As a servant leader, the primary responsibility of the Scrum Master is to help the development team perform. This includes removing obstacles that may impede the team from performing. Defining the vision:   The Product Owner’s main task is to define the vision of the product to the development team. This involves helping them understand the reason for the product being built, its usefulness for the clients and stakeholders, how it can evolve in the future and what it is expected to achieve. Giving the development team a correct vision of the product will help them work better. Helping team members do Scrum:   A Scrum Master is well versed with Scrum processes and tools. It’s the Scrum Master’s primary responsibility to ensure that the team adheres to Scrum processes during the development of the product. Being the bridge between stakeholders and team:   As the go-between the development team and the customers, it is the Product Owner’s responsibility to get each party what they need to be happy. In the development team’s case, the product owner has to ensure that they have understood without any ambiguity, what needs to be built and with respect to the stakeholders, product owner has to ensure that they get the product that they have asked for.   At the same time, the product owner must maintain a correct balance between the two and ensure that there is complete transparency and there is no over commitment on requirements to either side.   Arranges stand up meetings: The daily stand-up meetings are an essential part of Scrum. The Scrum Master facilitates these meetings and ensures that all issues are addressed and the team is able to perform towards reaching its sprint goal. Meet with all those involved with the product: This includes meeting stakeholders, development team and all those who wish to discuss the product roadmap. These discussions could range from current product backlog items to future releases to any technical information the stakeholder may need. Sets up an environment where the team can perform more effectively: The development team develops the product, and a happy team means a well-built product and satisfied customers.   The team must be allowed to work in an environment that is free of distractions and conducive to innovation and research.   The Scrum Master makes sure that such an environment is provided to the team. Maximises Product Value:   The Product Owner maximises product value by identifying what items in the product backlog need to be tackled first. Continuous prioritization and ordering of product backlog is an important responsibility of the product owner to ensure that high priority work gets into production first for release. Helps Product Owner with product backlog:   The Scrum Master aids the development team and the Product Owner with effective product backlog management.   This they do by facilitating Scrum events, product planning and by helping the team to identify backlog items. Manages Product Backlog:   Creating and updating the backlog is a major part of the product owner’s responsibility. They have to sequence, prioritise and ensure that the development time is not wasting time or resources in doing the wrong tasks. Updating the product backlog is an on-going responsibility of the Product Owner.   Promoting Scrum in the enterprise:   The Scrum Master has a greater responsibility than that of leading the team, and that is the promotion of Scrum and transformation of the entire organization.   This they do by coaching and helping teams and departments understand Scrum and develop an Agile mind-set. Explaining Scrum:   You may be working with a team that is new to Scrum or stakeholders who are not aware of Scrum processes.   As a Product Owner you will be expected to help your team understand about the Scrum processes that will be followed during every stage of product development while also helping the stakeholders understand how Scrum is being used to develop the product.   Here are some of the frequently asked questions around Scrum Master vs  Product Owner Which is the one most important service a Scrum Master provides to the Product Owner? The most important help a Scrum Master gives the Product Owner is in the management of the product backlog.   While the primary responsibility of the product backlog management lies with the Product Owner, the Scrum Master pitches in when there are too many things to handle and the Product Owner is unable to perform all activities simultaneously. The Scrum Master is also the perfect bridge between the Product Owner and the development team, helping the team understand the vision of the Product Owner and helping them realise this vision. Are Scrum Master and Product Owner the same person? This is a highly debated question in the Agile world. Some experts are of the view that there are clear differences between the two roles and hence there should be two individuals to manage these two roles.   The Product Owner should have an overall vision of the client’s requirements. Due to this reason, the Scrum Master needs the Product Owner; whereas the project team requires the Scrum Master to help them deliver by creating an atmosphere conducive to development and innovation. Who validates the product delivered in Scrum? The product backlog is ordered on the basis of the value of the items being delivered. Though the value is influenced by several factors including the complexity, risks associated and criticality, these are not the basis for calculating value.   The value of the product is validated by the Product Owner who orders the product backlog. Conclusion The Scrum Master and the Product Owner have mostly overlapping roles and responsibilities as well as overlapping skills.    The Scrum Master ensures project success, by assisting the product owner and the team in using the right Scrum processes for creating the end product and establishing the Agile principles. The Product Owner interacts with the users and customers, Stakeholders, the Development team and the Scrum Master to deliver a successful product.    The Product Owner and the Scrum Master are both invaluable members of a Scrum project team, as they build the perfect relation with the development team and strive to deliver the best results.
8783
Product Owner vs Scrum Master: Key Differences

Scrum Master vs Product Owner: The two most import... Read More

Useful links