Search

Series List

Filter

How Not to be Agile – Ultimate Guide to Sprint Planning

IntroductionHello and welcome to this, the fourth article in the series ‘How Not to be Agile’‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is!  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 reduce the potential benefits when an organisation, or part of it, embark on an Agile Transformation.Last time, I discussed the potential pitfalls with respect to the Product Backlog; this time, I will cover some of the misunderstandings and malpractices that I have come across to do with the ‘development timebox’ planning.  The most often used term for the ‘development timebox’ is the Sprint from Scrum; I will use this and other Scrum terminologies in this article but you can use whatever names you like; I shall put single quotes around Scrum role names to indicate that other names may be used.It is the planning, content and management of the Sprints that is important.I will start with a description of how product development is split into different time periods and then focus on the Sprint Planning ceremony.Product Development TimeboxesFigure 1 represents how an Agile product development is split into different timebox levels:The ‘complete’ product development is a timebox; it has a fixed end date; there may be maintenance periods after the product development is ‘complete’.The features of the product ‘go-live’ in a series of Release timeboxes, the content of each release contributing to the business benefits expected; usually, between 2 and 3 months.The content of each Release is developed in a series of Sprints, more of which below.The production of the artifacts produced in each Sprint may be timeboxed as well if appropriate.There are other ‘models’ that are used; some teams release at the end of each Sprint; Google is set to release new or modified functionality about every minute!Suffice to note here:The ‘High-Level Requirements Analysis’ in the Product Development line represents the activities that I covered in the first articles of this series.The Release timeboxes need to be decided before the development work starts.  It is useful if all Release timeboxes are of the same length but in practice, the first is usually longer than the rest and the last, shorter than rest; it depends on the product and organisation.What is a Sprint?For those who have heard the term ‘Sprint’ but not quite sure what it means, a Sprint is a fixed period of time in which ‘requirements’ are developed from the name to a fully working part of the final product, all done by a fixed size team (see ‘How not to be Agile 3. Product Backlog’ {Insert link to published article} for discussion about ‘The Iron Triangle’)’Having achieved an agreed, prioritised and estimated Product Backlog, the Development Team need to decide how long their Sprints will be; usually 2 to 3 weeks but can be as short a one week or as long as 4 weeks depending on the organisation’s circumstances and the nature of the product to be developed.  If it is thought necessary to have Sprint lengths greater than 4 weeks, then an in-depth analysis of the reasons for this must be made and changes, probably to the organisation, must be implemented so that the Sprint lengths can be reduced; more than 4 weeks between wider stakeholder reviews are too long and can lead to a lot of wasted work.It is worth noting here that once the Development Team has chosen their Sprint length, it remains the same for the whole product development unless something major happens which requires a change to release plans. Let’s see the purpose and steps for an effective Agile Sprint Planning.Sprint Planning DefinitionThere is a popular myth that Agile requires no planning; the ‘Nike’ approach –  ‘Just Do It’.Nothing is further than the truth; there are more planning ‘events’ in any Agile framework than any waterfall method that I have come across; we just plan at different levels.The first ‘ceremony’ of any Sprint is Sprint Planning  whereby the Development Team agree with the ‘Product Owner’ what the Sprint Goal is and which Product Backlog Items (PBI), that will contribute to that goal, will be attempted during the Sprint.Sprint Planning AttendeesIt is important that all of the Development Team, both full and part-time, the ‘Scrum Master’ and the ‘Product Owner’ attend the Sprint Planning as a minimum:The ‘Product Owner’ needs to be there to set the Sprint Goal, agree the PBI to be attempted in business order and agree on the Sprint MVP.The whole Development Team needs to be there because all team members have to agree on the Sprint Plan; if any team member is absent, he/she may feel that the work has been ‘foisted’ upon them and will have reduced motivation to do it.The ‘Scrum Master’ needs to be there to listen to the conversations so that they can keep a ‘fly on the wall’ view of the team during the Sprint and remind any team member that may be straying from the plan.Sprint GoalThis is a widely misunderstood part of Agile; there are many organisations that think that the Sprint Goal is to complete all the chosen PBI; it is not.A Sprint Goal helps the Development Team focus on a narrow aspect of the overall product, for example:“The Sprint Goal is to complete as many of the payment methods as possible”For a ‘retail’ website, there may be many possible payment methods such as credit/debit cards, PayPal, WorldPay etc.  There will no doubt be some ‘common’ aspects to all payment methods that will need to be developed and each method will have its own ‘specialised’ aspects; it is unlikely that all payment methods could be developed in oneSprint unless there was a great deal of reuse from other products.  Therefore, the customers’ most preferred payment methods may be in the Sprint’s MVP; others that cannot be completed in the Sprint go back into the Product Backlog in their respective business value order for consideration in later Sprints.You can think of a Sprint Goal as the Sprint Vision similar to the Product Development Vision that I discussed in the first article in this series. {Insert link to published article}Case Study 1:In one organisation that I coached in, when I arrived, they did not have ‘Sprint Goals’.  The teams worked out their capacity and ‘filled’ the Sprint with PBI estimated to fit that capacity.  The ‘Sprint Goal’ as far as management was concerned was to complete all the PBI in Sprint that was chosen during Sprint Planning.What you have in this situation is fixed time, fixed team and fixed requirements; recognise that? It’s a Waterfall.Because, like all of us, the team members were not that good at estimating, were reliant on external resources that it had no control over and did not know all the SprintBacklog Items (SBI) at Sprint Planning , the teams consistently ‘failed’ to complete all the Sprint Planning chosen PBI  in the Sprint.The immediate consequence of this was management ‘getting on the teams’ backs’ for not working hard enough.  Morale sank and the team members blamed Agile!The teams learned to ‘game’ the PBI estimating by increasing estimates so that less PBI were chosen at Sprint Planning.  One team even marked unfinished PBI as complete at the end of the Sprint and then ‘resurrected’ them for the next Sprint.Lessons:By not having a Sprint Goal, the ‘Product Owners’ lost the chance to focus Sprint development incoherent areasBy expecting Development Teams to complete all published SBI within the Sprint, team morale dropped, the team members blamed Agile and they focused on making themselves look better in the eyes of management rather than producing the best business value.Sprint Planning Inputs1) The Product Backlog:  The initial estimation of the next most important PBI to contribute to the Spring Goal was probably done sometime before Sprint Planning; the Development Team will have learned a lot from previous Sprints so those initial estimates may be way off.Most teams carry out Backlog Refinement during a Sprint to make sure that the next most important PBI are ready to be considered for the next Sprint; I will discuss Backlog Refinement in a later article.If Backlog Refinement is not done separately, it must be done as part of the Sprint Planning.2) Review Comments from the previous Sprint:  There may have been comments of the development to date from the previous Sprint Review session that may affect what needs to be done in the current Sprint.  These may include:High-priority changes required to previously developed PBI; unlikely but not unheard of.Changes to organisation strategy or tactics that mean necessary changes to Product Backlog ordering.Additional PBI that need to be added to the Product Backlog.3) ‘Inspect and Adapt’ Improvements:  The last ceremony of any Sprint is the Retrospective where the team discusses possible improvements to the process they are following and make prioritised plans to implement the improvements.The process improvement items must be considered when the team decides on what is possible in the Sprint; new processes sometimes slow production until they ‘bed-in’.4) The Risk List/Register: One Sprint Planning input that is mostly overlooked is the Development Risk List/Register.  Without going into the detail of Risk Analysis, one of its aspects is to determine when a particular risk may become an issueProbable risks need to be considered during Sprint Planning because any mitigation work that needs to be done will reduce the number of PBI that may be attempted.Sprint Planning Process1) Establish Probable Sprint2) Velocity Sprint Planning starts with the team deciding what their Sprint Velocity is expected to be from the following:Team Sprint Capacity: For most Agile teams, their Sprint capacity is based on the team’s Velocity; the average number of Story Points completed over the last 3 or 4 Sprints.  For organisations ‘wedded’ to time estimation, the team’s Sprint capacity is the number of team members multiplied by the number of working hours in the day multiplied by the number of working days in the Sprint.For teams using Velocity to estimate their capacity, any team member absence during the Sprint must be used to reduce the Velocity with which to plan the Sprint.Risk Analysis:  The Risk List/Register must be reviewed to see if any of the risks may become issues during the Sprint.  If so, then decisions must be made whether to:A) Implement any risk mitigation work in order to prevent the issue.B) Plan what to do if the risk does create an issue.C) ‘Ignore’ the risk if the probability of it causing an issue is low.Again, if the team consider that significant work must be done for managing any risks, then the team Velocity must be reduced to account for the risk management work.Review Comments:  The team must inspect the Review Comments from the previous Sprint Review to see if any remedial work is needed.  If so, the work must be estimated and, again, the team velocity must be reduced.Ideally, Review Comments that necessitate remedial work should become PBI and ordered by the Product Owner before Sprint Planning; if this is the case, there is no need to reduce the team’s Velocity.Inspect and Adapt:  If the team has decided that they will attempt process improvements during the Sprint, it needs to consider if any of these improvements will cause extra work and if so, what effect the extra work may have on the team Velocity.You may think that process improvements should result in a higher Velocity; however, if the process improvement is to do with getting better quality, then the Velocity may go down.Case Study 2:For one engagement, I was working as an analyst/designer and I raised a concern with the ‘Agile PM’ that I could not find the Risk List/Register so that I could add risks as they came up.  He was wary about adding risks because he believed that people would perceive that the more risks there were, the less he was capable of doing his job!After persuading him to let me see the Risk List, I found it to be wholly inadequate; the risks in the List were few, they weren’t ordered and there was no indication of impact severity, probability of becoming issues or when they may occur; there was no mitigation in place for any of them.I persuaded the ‘Product Owner’ that we should have a Risk Workshop with the Development Team and stakeholders.  At the end of the half-day workshop, we had a pretty good Risk List.BUT – the ‘Agile PM’ insisted that he, as the Risk and Issue Manager, would have sole control of it; he would not let anyone see it except himself!As time went on, not being able to see the Risk List, we in the Development Team could not take potential risks into our planning and when risks did turn into issues, we couldn’t see the agreed mitigation.  Progress slowed.LessonsAlways take time before development starts to get a good Risk List/Register not just including the ‘normal’ risks but also including the risks of being Agile in an organisation just beginning to transform.By all means, have the Agile PM/’Scrum Master’ being the sole ‘controller’ of the Risk List; all new risks and changes to existing risks must be passed through the Agile PM/’Scrum Master’ just like the ‘Product Owner’ controls the Product Backlog.The Risk List/Register must be available to the Development Team at Sprint Planning to adequately estimate its Sprint Velocity.2) Establish the Sprint GoalSee above.3) Choose Probable Sprint PBIThe Product Owner should initially choose the next most important PBI that will satisfy the Sprint Goal.The Development Team compare the revised Sprint Velocity with the total Story Points for the initial chosen PBI.The Development Team negotiate with the Product Owner to get the agreed SBI and the Sprint MVP; I discussed the MVP for the Product Backlog in my previous article, ‘How Not to Be Agile 3. Sprint Backlog’; the process to determine the Sprint MVP is the same as for the Product Backlog MVP.Create and publish the Sprint Plan.The team members decide who will do what and when and create the Team/Sprint Board (kanban).4) How Long Should Sprint Planning Take?There is no definitive answer to this question; it depends on the team, the product and the environment.  However, empirical observation of ‘successful’ teams indicates that for a 2-week Sprint, Sprint Planning should take between 2 and 4 hours.Case Study 3:The worst example of ‘non-Agile’ Sprint Planning that I have come across is with the same organisation that I spoke about in Case Study 1 aboveThe Product Backlog was filled in a ‘first come, first served’ order unless a ‘show-stopper’ turned up.There was no Risk Register.There was no Sprint Review Comments because there was no business representation at the Sprint Reviews.There was no ‘Inspect and Adapt’ plans because the teams didn’t really know what Retrospectives were supposed to be for; they held them because they were told to but they used it as a ‘team meeting’ chat.Each team’s Sprint Planning process consisted of:Looking at the next PBI and breaking them down into tasksEstimating the tasks in timeSelecting the PBI whose total estimated time added up to the team’s Sprint time capacity; senior management had ‘allowed’ a ‘contingency’ in that the Sprint time capacity was 80% of the total team time capacity.However, the team member’s task estimation was not done with any enthusiasm because they knew that ‘requirements’ would be arriving in the Sprint that represented between approximately 10% and 50% of the their capacity; there was no pattern to this extra work that could be used to modify the team’s Sprint capacity.What was worse was that senior management measured teams by the number of Sprint Backlog Items (SBI) that had been published in the Sprint Plan; the published list was never completed because of the ‘break-ins’.Each team was taking between 6 and 8 hours to complete Sprint Planning; producing a Sprint Plan that they knew would not work!I asked the teams if they thought their Sprint Planning was ‘reasonable’.  The answer worried me greatly.  The culture of the organisation was ‘what the management wants, the management gets’ and the teams had been used to criticism for years.  The Agile transformation, instigated by the senior management, was an attempt to change this situation but all of the management had probably had less training than the teams.Lessons:When finding ‘bad’ practices in teams, find out the root cause of the ‘bad’ practicesIf, as a ‘Product Owner’, ‘Scrum Master’ or Agile Coach, you do not have access to senior management, introduce a ‘disruptive experiment’; devise an effective Sprint Planning process for one team and when the management ask why things are so different, you will get the access to the management that you need to explain why their ‘edicts’ were probably less than optimal and possibly misinterpreted by the teams.Sprint Planning Output – The Sprint PlanThe Sprint Plan shows:A list of ordered PBI that will be attempted during the Sprint (the SBI) along with the Sprint MVP.A list of workshops that need to involve people outside of the Development Team with the people needed; the list includes dates, times and places for the workshops.A reminder of the Sprint Review date, time and place.The Sprint Plan is published to ALL stakeholders including those who will be required to help during the Sprint.What the Sprint Plan is NotThe Sprint Plan is not:A detailed, day-by-day Gantt Chart of tasks:  What the team does in the way of tasks is for the team onlyThe Team Board – Whether it is ‘Sticky Notes’ on the wall or an electronic representation of that, the Team Board is updated at least daily;  unless something major happens, the Sprint Plan is not changed after publication.Case Study 3:Unfortunately, there is one Agile ‘standards’ organisation that occasionally has a question in its certification exams:Q.  “How often can the Sprint Plan be amended?”A.  “Every day”Rationale.  “The Team Board is updated at least every day during the Daily Stand-up”I guess the organisation has the right to equate a Sprint Plan with the Team/Sprint Board but this has the effect that management and stakeholders need to look at the Board to see what the ‘current’ plan is; they cannot help but interpret the Board with some aspect of Sprint progress and if they do not like what they see, there is a temptation to intervene with the team.Lessons:Progress within a Sprint should be solely the responsibility of the Development Team facilitated by the ‘Scrum Master’.Remember – the sole measure of Sprint success is that the SBI representing the MVP have been completed.ConclusionEffectively preparing for Sprint Planning, following the best practices of Sprint Planning is essential for Sprint success:The ‘Product Owner’ must set the Sprint Goal.All factors influencing the expected team Sprint Velocity must be considered.Initial estimates of PBI done when creating the Product Backlog must be verified in the light of experience gained so far.The Development Team must agree with the ‘Product Owner’ which PBI to take into the Sprint Plan and agree on the Sprint MVP.The Sprint Plan is for the management and stakeholders.The Team/Sprint Board is for the Development Team.
Rated 4.0/5 based on 1 customer reviews
How Not to be Agile – Ultimate Guide to Sprint Planning 218
  • by Steve Ash
  • 08th Oct, 2018
  • Last updated on 05th Mar, 2019
  • 4 mins read
How Not to be Agile – Ultimate Guide to Sprint Planning

Introduction

Hello and welcome to this, the fourth article in the series ‘How Not to be Agile’

‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is!  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 reduce the potential benefits when an organisation, or part of it, embark on an Agile Transformation.

Last time, I discussed the potential pitfalls with respect to the Product Backlog; this time, I will cover some of the misunderstandings and malpractices that I have come across to do with the ‘development timebox’ planning.  The most often used term for the ‘development timebox’ is the Sprint from Scrum; I will use this and other Scrum terminologies in this article but you can use whatever names you like; I shall put single quotes around Scrum role names to indicate that other names may be used.

It is the planning, content and management of the Sprints that is important.

I will start with a description of how product development is split into different time periods and then focus on the Sprint Planning ceremony.

Product Development Timeboxes
Product Development, Releases and Sprints

Figure 1 represents how an Agile product development is split into different timebox levels:

  • The ‘complete’ product development is a timebox; it has a fixed end date; there may be maintenance periods after the product development is ‘complete’.
  • The features of the product ‘go-live’ in a series of Release timeboxes, the content of each release contributing to the business benefits expected; usually, between 2 and 3 months.
  • The content of each Release is developed in a series of Sprints, more of which below.
  • The production of the artifacts produced in each Sprint may be timeboxed as well if appropriate.

There are other ‘models’ that are used; some teams release at the end of each Sprint; Google is set to release new or modified functionality about every minute!

Suffice to note here:

  • The ‘High-Level Requirements Analysis’ in the Product Development line represents the activities that I covered in the first articles of this series.
  • The Release timeboxes need to be decided before the development work starts.  It is useful if all Release timeboxes are of the same length but in practice, the first is usually longer than the rest and the last, shorter than rest; it depends on the product and organisation.

What is a Sprint?

For those who have heard the term ‘Sprint’ but not quite sure what it means, a Sprint is a fixed period of time in which ‘requirements’ are developed from the name to a fully working part of the final product, all done by a fixed size team (see ‘How not to be Agile 3. Product Backlog’ {Insert link to published article} for discussion about ‘The Iron Triangle’)’

Having achieved an agreed, prioritised and estimated Product Backlog, the Development Team need to decide how long their Sprints will be; usually 2 to 3 weeks but can be as short a one week or as long as 4 weeks depending on the organisation’s circumstances and the nature of the product to be developed.  If it is thought necessary to have Sprint lengths greater than 4 weeks, then an in-depth analysis of the reasons for this must be made and changes, probably to the organisation, must be implemented so that the Sprint lengths can be reduced; more than 4 weeks between wider stakeholder reviews are too long and can lead to a lot of wasted work.

It is worth noting here that once the Development Team has chosen their Sprint length, it remains the same for the whole product development unless something major happens which requires a change to release plans. Let’s see the purpose and steps for an effective Agile Sprint Planning.

Sprint Planning Definition

There is a popular myth that Agile requires no planning; the ‘Nike’ approach –  ‘Just Do It’.

Nothing is further than the truth; there are more planning ‘events’ in any Agile framework than any waterfall method that I have come across; we just plan at different levels.

The first ‘ceremony’ of any Sprint is Sprint Planning  whereby the Development Team agree with the ‘Product Owner’ what the Sprint Goal is and which Product Backlog Items (PBI), that will contribute to that goal, will be attempted during the Sprint.

Sprint Planning Attendees

It is important that all of the Development Team, both full and part-time, the ‘Scrum Master’ and the ‘Product Owner’ attend the Sprint Planning as a minimum:

The ‘Product Owner’ needs to be there to set the Sprint Goal, agree the PBI to be attempted in business order and agree on the Sprint MVP.

The whole Development Team needs to be there because all team members have to agree on the Sprint Plan; if any team member is absent, he/she may feel that the work has been ‘foisted’ upon them and will have reduced motivation to do it.

The ‘Scrum Master’ needs to be there to listen to the conversations so that they can keep a ‘fly on the wall’ view of the team during the Sprint and remind any team member that may be straying from the plan.

Sprint Goal

This is a widely misunderstood part of Agile; there are many organisations that think that the Sprint Goal is to complete all the chosen PBI; it is not.

A Sprint Goal helps the Development Team focus on a narrow aspect of the overall product, for example:

“The Sprint Goal is to complete as many of the payment methods as possible”

For a ‘retail’ website, there may be many possible payment methods such as credit/debit cards, PayPal, WorldPay etc.  There will no doubt be some ‘common’ aspects to all payment methods that will need to be developed and each method will have its own ‘specialised’ aspects; it is unlikely that all payment methods could be developed in one
Sprint unless there was a great deal of reuse from other products.  

Therefore, the customers’ most preferred payment methods may be in the Sprint’s MVP; others that cannot be completed in the Sprint go back into the Product Backlog in their respective business value order for consideration in later Sprints.

You can think of a Sprint Goal as the Sprint Vision similar to the Product Development Vision that I discussed in the first article in this series. {Insert link to published article}

Case Study 1:

In one organisation that I coached in, when I arrived, they did not have ‘Sprint Goals’.  The teams worked out their capacity and ‘filled’ the Sprint with PBI estimated to fit that capacity.  The ‘Sprint Goal’ as far as management was concerned was to complete all the PBI in Sprint that was chosen during Sprint Planning.

What you have in this situation is fixed time, fixed team and fixed requirements; recognise that? It’s a Waterfall.

Because, like all of us, the team members were not that good at estimating, were reliant on external resources that it had no control over and did not know all the Sprint

Backlog Items (SBI) at Sprint Planning , the teams consistently ‘failed’ to complete all the Sprint Planning chosen PBI  in the Sprint.

The immediate consequence of this was management ‘getting on the teams’ backs’ for not working hard enough.  Morale sank and the team members blamed Agile!

The teams learned to ‘game’ the PBI estimating by increasing estimates so that less PBI were chosen at Sprint Planning.  One team even marked unfinished PBI as complete at the end of the Sprint and then ‘resurrected’ them for the next Sprint.

Lessons:

  1. By not having a Sprint Goal, the ‘Product Owners’ lost the chance to focus Sprint development incoherent areas
  2. By expecting Development Teams to complete all published SBI within the Sprint, team morale dropped, the team members blamed Agile and they focused on making themselves look better in the eyes of management rather than producing the best business value.

Sprint Planning Inputs

1) The Product Backlog:  The initial estimation of the next most important PBI to contribute to the Spring Goal was probably done sometime before Sprint Planning; the Development Team will have learned a lot from previous Sprints so those initial estimates may be way off.

Most teams carry out Backlog Refinement during a Sprint to make sure that the next most important PBI are ready to be considered for the next Sprint; I will discuss Backlog Refinement in a later article.

If Backlog Refinement is not done separately, it must be done as part of the Sprint Planning.

2) Review Comments from the previous Sprint:  There may have been comments of the development to date from the previous Sprint Review session that may affect what needs to be done in the current Sprint.  These may include:

  • High-priority changes required to previously developed PBI; unlikely but not unheard of.
  • Changes to organisation strategy or tactics that mean necessary changes to Product Backlog ordering.
  • Additional PBI that need to be added to the Product Backlog.

3) ‘Inspect and Adapt’ Improvements:  The last ceremony of any Sprint is the Retrospective where the team discusses possible improvements to the process they are following and make prioritised plans to implement the improvements.

The process improvement items must be considered when the team decides on what is possible in the Sprint; new processes sometimes slow production until they ‘bed-in’.

4) The Risk List/Register: One Sprint Planning input that is mostly overlooked is the Development Risk List/Register.  Without going into the detail of Risk Analysis, one of its aspects is to determine when a particular risk may become an issue

Probable risks need to be considered during Sprint Planning because any mitigation work that needs to be done will reduce the number of PBI that may be attempted.

Sprint Planning Process

1) Establish Probable Sprint

2) Velocity Sprint Planning starts with the team deciding what their Sprint Velocity is expected to be from the following:

  • Team Sprint Capacity: For most Agile teams, their Sprint capacity is based on the team’s Velocity; the average number of Story Points completed over the last 3 or 4 Sprints.  

    For organisations ‘wedded’ to time estimation, the team’s Sprint capacity is the number of team members multiplied by the number of working hours in the day multiplied by the number of working days in the Sprint.

    For teams using Velocity to estimate their capacity, any team member absence during the Sprint must be used to reduce the Velocity with which to plan the Sprint.

  • Risk Analysis:  The Risk List/Register must be reviewed to see if any of the risks may become issues during the Sprint.  If so, then decisions must be made whether to:

    A) Implement any risk mitigation work in order to prevent the issue.
    B) Plan what to do if the risk does create an issue.
    C) ‘Ignore’ the risk if the probability of it causing an issue is low.

Again, if the team consider that significant work must be done for managing any risks, then the team Velocity must be reduced to account for the risk management work.

  1. Review Comments:  The team must inspect the Review Comments from the previous Sprint Review to see if any remedial work is needed.  If so, the work must be estimated and, again, the team velocity must be reduced.
    Ideally, Review Comments that necessitate remedial work should become PBI and ordered by the Product Owner before Sprint Planning; if this is the case, there is no need to reduce the team’s Velocity.
  2. Inspect and Adapt:  If the team has decided that they will attempt process improvements during the Sprint, it needs to consider if any of these improvements will cause extra work and if so, what effect the extra work may have on the team Velocity.
    You may think that process improvements should result in a higher Velocity; however, if the process improvement is to do with getting better quality, then the Velocity may go down.

Case Study 2:

For one engagement, I was working as an analyst/designer and I raised a concern with the ‘Agile PM’ that I could not find the Risk List/Register so that I could add risks as they came up.  He was wary about adding risks because he believed that people would perceive that the more risks there were, the less he was capable of doing his job!

After persuading him to let me see the Risk List, I found it to be wholly inadequate; the risks in the List were few, they weren’t ordered and there was no indication of impact severity, probability of becoming issues or when they may occur; there was no mitigation in place for any of them.

I persuaded the ‘Product Owner’ that we should have a Risk Workshop with the Development Team and stakeholders.  At the end of the half-day workshop, we had a pretty good Risk List.

BUT – the ‘Agile PM’ insisted that he, as the Risk and Issue Manager, would have sole control of it; he would not let anyone see it except himself!

As time went on, not being able to see the Risk List, we in the Development Team could not take potential risks into our planning and when risks did turn into issues, we couldn’t see the agreed mitigation.  Progress slowed.

Lessons

  • Always take time before development starts to get a good Risk List/Register not just including the ‘normal’ risks but also including the risks of being Agile in an organisation just beginning to transform.
  • By all means, have the Agile PM/’Scrum Master’ being the sole ‘controller’ of the Risk List; all new risks and changes to existing risks must be passed through the Agile PM/’Scrum Master’ just like the ‘Product Owner’ controls the Product Backlog.
  • The Risk List/Register must be available to the Development Team at Sprint Planning to adequately estimate its Sprint Velocity.

2) Establish the Sprint Goal

See above.

3) Choose Probable Sprint PBI

  • The Product Owner should initially choose the next most important PBI that will satisfy the Sprint Goal.
  • The Development Team compare the revised Sprint Velocity with the total Story Points for the initial chosen PBI.
  • The Development Team negotiate with the Product Owner to get the agreed SBI and the Sprint MVP; I discussed the MVP for the Product Backlog in my previous article, ‘How Not to Be Agile 3. Sprint Backlog’; the process to determine the Sprint MVP is the same as for the Product Backlog MVP.
  • Create and publish the Sprint Plan.
  • The team members decide who will do what and when and create the Team/Sprint Board (kanban).


4) How Long Should Sprint Planning Take?

There is no definitive answer to this question; it depends on the team, the product and the environment.  However, empirical observation of ‘successful’ teams indicates that for a 2-week Sprint, Sprint Planning should take between 2 and 4 hours.

Case Study 3:
The worst example of ‘non-Agile’ Sprint Planning that I have come across is with the same organisation that I spoke about in Case Study 1 above

  • The Product Backlog was filled in a ‘first come, first served’ order unless a ‘show-stopper’ turned up.
  • There was no Risk Register.
  • There was no Sprint Review Comments because there was no business representation at the Sprint Reviews.
  • There was no ‘Inspect and Adapt’ plans because the teams didn’t really know what Retrospectives were supposed to be for; they held them because they were told to but they used it as a ‘team meeting’ chat.

Each team’s Sprint Planning process consisted of:

  • Looking at the next PBI and breaking them down into tasks
  • Estimating the tasks in time
  • Selecting the PBI whose total estimated time added up to the team’s Sprint time capacity; senior management had ‘allowed’ a ‘contingency’ in that the Sprint time capacity was 80% of the total team time capacity.

However, the team member’s task estimation was not done with any enthusiasm because they knew that ‘requirements’ would be arriving in the Sprint that represented between approximately 10% and 50% of the their capacity; there was no pattern to this extra work that could be used to modify the team’s Sprint capacity.

What was worse was that senior management measured teams by the number of Sprint Backlog Items (SBI) that had been published in the Sprint Plan; the published list was never completed because of the ‘break-ins’.

Each team was taking between 6 and 8 hours to complete Sprint Planning; producing a Sprint Plan that they knew would not work!

I asked the teams if they thought their Sprint Planning was ‘reasonable’.  The answer worried me greatly.  The culture of the organisation was ‘what the management wants, the management gets’ and the teams had been used to criticism for years.  The Agile transformation, instigated by the senior management, was an attempt to change this situation but all of the management had probably had less training than the teams.

Lessons:

  1. When finding ‘bad’ practices in teams, find out the root cause of the ‘bad’ practices
  2. If, as a ‘Product Owner’, ‘Scrum Master’ or Agile Coach, you do not have access to senior management, introduce a ‘disruptive experiment’; devise an effective Sprint Planning process for one team and when the management ask why things are so different, you will get the access to the management that you need to explain why their ‘edicts’ were probably less than optimal and possibly misinterpreted by the teams.

Sprint Planning Output – The Sprint Plan
The Sprint Plan shows:

  • A list of ordered PBI that will be attempted during the Sprint (the SBI) along with the Sprint MVP.
  • A list of workshops that need to involve people outside of the Development Team with the people needed; the list includes dates, times and places for the workshops.
  • A reminder of the Sprint Review date, time and place.

The Sprint Plan is published to ALL stakeholders including those who will be required to help during the Sprint.

What the Sprint Plan is Not

The Sprint Plan is not:

  • A detailed, day-by-day Gantt Chart of tasks:  What the team does in the way of tasks is for the team only
  • The Team Board – Whether it is ‘Sticky Notes’ on the wall or an electronic representation of that, the Team Board is updated at least daily;  unless something major happens, the Sprint Plan is not changed after publication.

Case Study 3:

Unfortunately, there is one Agile ‘standards’ organisation that occasionally has a question in its certification exams:

Q.  “How often can the Sprint Plan be amended?”
A.  “Every day”

Rationale.  “The Team Board is updated at least every day during the Daily Stand-up”

I guess the organisation has the right to equate a Sprint Plan with the Team/Sprint Board but this has the effect that management and stakeholders need to look at the Board to see what the ‘current’ plan is; they cannot help but interpret the Board with some aspect of Sprint progress and if they do not like what they see, there is a temptation to intervene with the team.

Lessons:

  1. Progress within a Sprint should be solely the responsibility of the Development Team facilitated by the ‘Scrum Master’.
  2. Remember – the sole measure of Sprint success is that the SBI representing the MVP have been completed.

Conclusion
Effectively preparing for Sprint Planning, following the best practices of Sprint Planning is essential for Sprint success:

  • The ‘Product Owner’ must set the Sprint Goal.
  • All factors influencing the expected team Sprint Velocity must be considered.
  • Initial estimates of PBI done when creating the Product Backlog must be verified in the light of experience gained so far.
  • The Development Team must agree with the ‘Product Owner’ which PBI to take into the Sprint Plan and agree on the Sprint MVP.
  • The Sprint Plan is for the management and stakeholders.
  • The Team/Sprint Board is for the Development Team.
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 *

1 comments

Donald Hope 16 Nov 2018

Very circumstantial info Thanks.

Suggested Blogs

What is Scrum Alliance® Membership?

The certification offered by Scrum Alliance® enables you to gain an understanding of the agile mindset and learn about Scrum roles, events, and artifacts. But what is Scrum Alliance®? It is a non-profit organisation that helps to create joyful, prosperous, and sustainable workplaces by inspiring and guiding the individual, leaders, and organisations with agile practices, principles, and values.Scrum Alliance® also has a strong membership community that gives an extra boost to your passion of agile journey. The membership fee which you need to pay is $50 and you need to renew your membership every year. It is an optional service which gives you access to benefits that are exclusively available for the members. The benefits include access to local user groups, deep discounts off Global and Regional Scrum Gatherings, AgileCareers job board, and more. Now let’s discuss the offerings of Scrum Alliance® Membership in details.Scrum Alliance® Membership perksAs we have already discussed above, you don’t need to purchase a one-year Scrum Alliance Membership in order to take up a Scrum Alliance® course or earn a certification. Also, you do not get direct access to the online CSM® test. But you receive a complimentary membership for two years once you earn an initial certification from Scrum Alliance®, like CSM®, CSPO®, CSD®.Now let’s take a look at the perks of having a Scrum Alliance Membership. They are:Earn discounts for Regional and Global Scrum GatheringsGrab the opportunity to join a User GroupWork as a volunteerYou can find a job or post one with AgileCareers.Benefits of having a Scrum Alliance® MembershipIf you are passionate about embarking on an exciting Agile journey, then registering for Scrum Alliance Membership will provide you with the required support for it. Sign up for a Scrum Alliance Membership and get an opportunity to connect with other Scrum practitioners around the world as a part of the largest, most established, and influential professional membership organisation in the Agile and Scrum community. Moreover, you can reap the following benefits out of the membership:1. ConnectGet an opportunity to learn and network with the industry experts by participating at in-person events, including Global and Regional Gathering. Need some extra membership benefits? Scrum Alliance Membership enables you to avail exclusive membership while registering for these events.2. CommunityOnce you become a Scrum Alliance Member, you get the opportunity to share knowledge and best practices by participating in 350+ User Groups as well as give back to the community through a wide range of volunteering opportunities.3. CareerGive a new direction to your career by getting exclusive access to the job board of Scrum Alliance i.e. AgileCareers.4. CalibrateScrum Alliance® offers you a plethora of new professional development resources. Get updates on new exclusive webinars, resources, insights, and research.5. CollaborateYou become eligible for special offers as soon as you become a Scrum Alliance Member. Transform and optimize your organisation by taking advantage of product and service benefits.Steps to renew your Scrum Alliance MembershipYour Scrum Alliance Membership lasts for only a year. You need to renew your membership at the end of every year by paying $50. The renewal of membership gives you access to local user groups, exclusive discounts on Global and Regional Scrum Gatherings, AgileCareer job portal, and more. But renewing your membership doesn’t renew your certification. Follow these steps to renew your Scrum Alliance Membership:Step 1:  Log in to your account.Step 2: In the next step, you need to click on ‘Hello, [Your Name]’ which you will find in the upper righthand corner.Step 3: Next, you need to select ‘My Dashboard’.Step 4: Now you need to look for the section labelled ‘Actions’.Step 5: In the next step, you need to click on ‘Renew Membership’.Step 6: Finally, you need to pay $50 for your membership dues as soon as you get redirected to PayPal.On a concluding noteScrum Alliance Membership opens your doors towards numerous benefits that you can reap while you continue with your Agile journey. It gives you access to regional as well as global learning opportunities with an extra benefit of availing discounts on registration for the events.Further, get an opportunity to mingle with 350+ User Groups to share knowledge and best practices. Also, grab the exclusive opportunity to find a new role for yourself to give your career a new dimension by getting access to AgileCareers.Hope this article helps you to make a wise move. All the best!
Rated 4.5/5 based on 11 customer reviews
5880
What is Scrum Alliance® Membership?

The certification offered by Scrum Alliance® enab... Read More

How to earn a Scrum Education Unit® (SEU®) from the Scrum Alliance

In the world of Agile, SEUs® stands for Scrum Education Units® (SEUs®), issued by the Scrum Alliance. It marks your participation, educational experience and continued proficiency in the underlying principles and practices of Scrum, while at the same time to maintain your certification. You can earn Scrum Education Units® (SEUs®) via completing various learning opportunities or educational training.  The process to earn SEUs® is easy and it will help you stay relevant as well as competitive in the market.Why do I need to earn SEUs®?SEUs® are required to renew foundational, advanced and professional-level certifications, which include CSM®, A-CSM®, CSP-SM®, CSPO®, A-CSPO®, CSP-PO®,  CSD®, and CSP®.SEUs® follow a ratio of 1:1, which means that for every hour spent in preparation or participation, you earn one SEU®.In order to maintain your certification for two more years, you need to submit an established number of Scrum Education Units® (SEUs®) along with a renewal fee.There are six categories from which you can choose from when selecting SEUs®, which has been discussed later in the blog.The following SEU® requirements have been in effect since February 4, 2019, with no change in the renewal fee.Certification TypeCertification (2-year term)SEUs RequiredRenewal Fee Per TermFoundationalCSM®, CSPO®, CSD®20$100AdvancedA-CSM®, A-CSPO®30$175ProfessionalCSP-SM®, CSP-PO®, CSP®40$250What are the different ways to earn SEUs®?There are six categories that you can choose from while selecting SEUs®:Category I: Scrum Alliance Scrum GatheringsParticipate in Scrum Alliance Global Gatherings, Scrum Alliance Regional Gatherings, Scrum Coaching Retreats, and Scrum Alliance-Sponsored Events, and Scrum Alliance-Endorsed User Group activities and events and earn SEUs®.Per day, a maximum of 8 SEUs® can be earned.The following are a few options for Scrum Alliance Scrum Gatherings:Attending Global Scrum GatheringAttending Regional Scrum GatheringAttending Scrum Alliance user group activityAttending Scrum Coaching RetreatAttending Scrum Alliance pre-event or post-event workshopAttending Scrum Alliance-sponsored eventAttending Scrum Alliance CSP Retreat  Category II: Scrum Alliance Courses or CoachingWork with Scrum Alliance CSTs, CTCs, CECs, and REPs to earn SEUs®. You can earn a maximum of 8 SEUs® after attending a full day training.Additional SEUs® can be earned by:Acquiring continuing education in advanced Scrum topics.Attending training courses conducted by CST®, like webinars, e-learning, recorded training, face-to-face courses.Attending training courses which are provided by Scrum Alliance® Registered Education Provider (REP).Participating in small or one-on-one group coachings provided by a CEC or CTC.Note: The CSTs, CECs, CTCs, or REPs should be verified as per the Member Directory on the Scrum Alliance website.The following are a few options for Scrum Alliance Courses or Coaching:Receiving CSM trainingReceiving CSPO trainingReceiving CSD trainingReceiving training from a CST (can be video training or eLearning)Receiving training from a Scrum Alliance REPReceiving coaching conducted by a CEC or CTCCategory III: Outside EventsYou can earn SEUs® by participating in other relevant events as well, other than the ones that are sponsored by Scrum Alliance. It includes Agile conferences, training from someone who is not a CST, regional meetings, or a REP course that does not fit according to the Category II.  Unlike Category II, activities in Category III include activities and services that you are receiving rather than providing.The following are a few options for Outside Events:Receiving face-to-face training outside of Scrum AllianceReceiving coaching or mentoring outside of Scrum Alliance vAttending user group events outside of Scrum AllianceAttending Scrum/Agile events outside of Scrum AllianceCategory IV: Volunteer ServiceScrum Alliance encourages you to give back to the community.  Therefore, you can earn SEUs® by providing non-compensated professional Scrum services, that is, you will be asked if you are not compensating for your volunteer work for your employer or another party.Category V: Independent LearningYou can earn SEUs® via independent learning activities such as preparing presentations, authoring relevant books, blogs or articles; watching a training video; reading books in-depth and then describing their benefits as a Scrum practitioner.The following are a few options for Independent Learning:Preparing a Scrum presentation (not delivering)Author a book, blog or articleWatch a Scrum/Agile video by an instructor other than a Scrum Alliance CSTRead a book on Scrum/AgileOther independent learningCategory VI: Other Collaborative LearningYou can earn SEUs® via various other collaborative learning activities with other Scrum practitioners. This category might not include submissions which belong to Category B or C.The following are a few options for Collaborative Learning:Co-training with the objective of learningReceiving training via live webinar which is delivered by any trainer other than a CSTOther collaborative learningWhat is the process for submitting SEUs®  for renewal? The following is the step-by-step process for SEUs® renewal:Log into your account on the Scrum Alliance page, https://www.scrumalliance.org/login.Click on the ‘My Settings’, which can be found on the upper right-hand area of your screen.Select ‘Certification Dashboard’.Under the ‘My Credentials’, go to the grey ‘Manage SEUs®’ button.Choose your SEU® category from the ‘Enter a Scrum Education Unit’  drop-down menu.Fill in all the details of all the required fields. Note: You cannot reuse an SEU® if it has been used to submit a prior renewal of certification or CSP® application.  Also, all of the SEUs® that is being used for renewal should be earned within the past two years. 
Rated 4.5/5 based on 12 customer reviews
9876
How to earn a Scrum Education Unit® (SEU®) from ...

In the world of Agile, SEUs® stands for Scrum Edu... Read More

Everything You Need to Know About Scrum Master

What is a Scrum Master?A deep understanding of Scrum roles is critical to implementing Scrum.Many times, this gets widely overlooked when organizations adopt Scrum for the first time. Even before Scrum can be useful for any team, a clear perception of “what is a Scrum Master” is important.Simply put, a Scrum Master is the coach and facilitator of a Scrum team. The Scrum guide describes Scrum Master as a person chiefly responsible for promoting and supporting Scrum. As rightly stated in the guide, a Scrum Master helps everyone understand the Scrum theory, practices, rules, and values. A converter of “doing Agile” to “being Agile” is what defines a Scrum Master. Essentially, a Scrum Master is a servant leader responsible for facilitating Scrum processes.That being said, a Scrum Master also helps people outside the Scrum team understand which of their interactions with the Scrum team are useful. This, in turn, helps the Scrum teams maximize the value created by them.According to Wikipedia, Scrum Master is a facilitator of the team responsible for removing the impediments to deliver the project target. The Scrum Master is not a traditional project manager and acts as a buffer between the team and any distracting influences.  What a Scrum master is “NOT”A better perception of “what is a Scrum Master” demands an understanding of “what a Scrum Master is not”. If you are in it for the long haul, this will help you become aware of the generic misconceptions around who a scrum master actually is.Well, a Scrum Master is not a:Project managerProduct OwnerA position (it is a role)Role above the teamIn this regard, it is also important to note that a Scrum Master is not an active participant in the daily scrum activities but only a moderator.So what is it that a scrum master does for real? Let us try to understand.What exactly does a Scrum Master do?Being a Scrum Master entails a lot more than the list of priority activities of a Scrum Master you come across nearly everywhere. In addition to moderating the team activities, a Scrum Master has to help teams live by Scrum values.A typical day in the life of a Scrum Master looks somewhat like below-Moderates team activitiesHelps organize meetingsKeeps scrum processes movingKeeps the team focused on current sprintEnsures a power balance among management, Product Owner, and the teamActively works with the PORemoves impedimentsHelps the team achieve sprint goalsMaintains transparency in processesHelps improve performanceEnsures quick delivery of the final productPromotes a constructive feedback cultureIdentifies hidden issues and helps prioritize and address themHelps build self-organizing teamsEncourages teams to learn from experienceWe shall discuss the roles and responsibilities of a Scrum Master in further details in the upcoming sections.What are the top qualities of the successful Scrum Masters?To be an effective Scrum Master, one has to be a Scrum enabler first. If you have had the chance to work with highly successful Scrum Masters, there a few patterns you must have observed. These are nothing but the key attributes seen in Scrum Masters of high-performing teams.Scrum Masters with these top qualities are found to lead their teams to success-Communication:Effective communication is one of the top skills for any role. A Scrum Master, however, should be adept in two-way communication. (S)he should be a good speaker and listener. An efficient Scrum Master should be able to listen, comprehend, repeat, summarize, energize, observe, write, simplify, critique, suggest, assert, chat, and present with equal ease.Responsibility and Ownership: Scrum Master is a representative of the Scrum team. As a Scrum Master, if you are capable of building and gaining trust among the team members, you should be able to represent them in their success or failure.Acknowledgment and appreciation: Genuine leadership entails valuing your colleague's efforts and enabling them to advance their performance. This is one of the top qualities of a Scrum Master, who happens to be a servant leader as well.Good leader, not a ruler A Scrum Master should not follow a command-and-control leadership. Instead, he should adhere to the principles of servant leadership, wherein decisions are made only after discussion with the team members instead of being directly imposed.Multitasker: As a Scrum Master, you should be able to juggle parallel tasks and manage important scrum events within defined timeframes. Assuming an ideal Scrum team of 6-9 members, you are responsible for managing today’s tasks and planning for tomorrow’s tasks along with arranging the Scrum events for the team members to resolve their queries, planning for the next Sprint, and release. Multitasking, in fact, is one of the top qualities of a Scrum Master.Resolve the obstacles and keep the team on track: The Scrum Master always focuses on keeping the team on track and resolving the obstacles that are blocking their way to deliver a quality product. These obstacles may include unwanted meetings, unwanted procedural complexity, work environment or any other challenge. He/She ensures that the team is away from the distractions that are hindering the project success.Encourage collaboration: A Scrum Master has to look into the daily activities of the team members. Also, the Scrum Master can share his/her experiences through seminars. conferences, and meetings with the team members. A good Scrum Master should encourage collaboration with the help of planning sessions, daily stand-ups, sprint planning, and sprint review meeting sessions.  Initiating latest technologies: A Scrum Master can use automated builds, simple designs, multi-level testing, automated development, and pair programming to reduce time and efforts while developing the project. He/she can also make use of the latest technologies and best practices that can help you in the early completion of the project.   Good coach for the team: A successful Scrum Master should understand the different phases that his/her team is undergoing and the importance of team building. The Scrum Master coaches the team members by building self-organizing teams, tracking the project, implementing simple methodology rules, and by creating project vision. Other than being a coach to the team to explain Scrum processes clearly and enforcing the practice for Agile, the Scrum Master should have basic technical and project management knowledge.Effective collaboration with the Product Owner: This is regarded as one of the key qualities of a Scrum Master. An effective Scrum Master should be able to collaborate with the Product Owner. While the role of a PO is to convey the user requirement to the Scrum team and push the team towards it, a Scrum Master facilitates a seamless execution of the processes. Together, the Scrum Master and Product Owner build a strong relationship with the team to provide the best results.Empathy: A Scrum Master develops many skills while working with team members. He/She builds his/her skills to develop emotions and to learn what the team members feel. This way, (s)he builds a strong connection with the team and understands their problems while also suggesting effective solutions.  A strong understanding of servant leadership and facilitation:The role of the Scrum Master is not to assign the tasks to the team, it is all about supporting the team members in achieving the project goals. Servant leadership, which is one of the fundamental qualities of a Scrum Master plays a key role here. By serving and encouraging the team in every way possible, a good scrum master always helps the team members attain their full potential. Needless to say, this has a direct positive impact on the business value they create as a team.A relentless approach to continuous delivery:A successful Scrum Master always tries to improve the way a team works. The best way to do this is to arrange the retrospective, where each team member identifies what went well and what went wrong in the initial Sprint. The team members learn from the mistakes and this leads to continuous improvement.A good relationship with the team:A Scrum Master may act as a team leader, but he/she doesn’t have the authority of a true manager. Eventually, a Scrum Master has to be cordial with the team members, if he/she wants to influence specific actions.Product, market, and domain knowledge:A Scrum Master need not have end-to-end technical knowledge and domain skills. However, a fundamental understanding of the product, markets, and software development processes, makes it easier for them to address challenges in project delivery.Encourage a self-organizing team:A scrum master should know when to express his views and should mostly allow the team to be self-organizing. That said, he should be actively listening to the team members’ inputs and learning points and guide the team to perform better in subsequent sprints.What are the essential skills of a Scrum Master?Though the Scrum Master role is complex and challenging, a diverse skill set allows them to become a great Scrum Master. Here are the Scrum Master competencies that help him/her succeed in the project:1. Organizing the teamKnowing the rules of the ScrumCommunicating internally and externallyReporting the status of the team membersCollecting the team members in the Sprint PlanningGuiding clearlyResolving the impedimentsEfficient facilitationImplementing collaborative engagement tools and techniques2. Improving the teamForming a good teamManaging the technical debtImproving team members’ activities by providing feedback and motivationImplemented continuous validated learningResponsible for making a change3. Establishing a self-organising teamDisplaying a servant leadershipExecuting the Scrum valuesDecide according to Agile methodologyOwing to the team members’ responsibilitiesInvolving every team member in planning4. Planning bigDiscussing with the team membersFinding and fixing the cross-team problemsImproving the cross-team technical practicesRoles and Responsibilities of a Scrum MasterThe Scrum Master’s role is pivotal to the success of a team. He/she is a process leader who helps the team understand Scrum values, principles, and practices. Some organizations practice rotation of Scrum Master roles among the team members; this is, once again, up to each Scrum Team.However, the roles of the Scrum Master include:The Agile framework custodian and process owner for the team.A facilitator and Servant Leader who never discourages but encourages and expects self-organization from the Agile development team.Build close collaboration across roles and functions in the organization, works on matters collectively and is not individualistic.Protect the team from distractions which include both external and internal.Remove impediments, so the team can focus on the development of work and tasks.Scrum Master is not typically a manager or lead, but he/she is an influential leader who does not do direct command and control.Scrum Master is a coach and advisor to the team and discussed issues encountered.Scrum Master should be equipped with basic technical and project management know-how, this is so that he/she understands the problems and is able to provide proper guidance and advice to the team.With Scrum gaining widespread attention in just about every sector, top industry majors like Microsoft, Honeywell, Ericsson, Bank of America, Cox Automotive, KPMG, etc. are focusing on the integration of Scrum into their existing frameworks. This trend has prompted more industries to invest in Agile and Scrum training.  Let’s see some more benefits of having a certified Scrum Master on a project.Why should you be interested in getting a Scrum Master Certification?Scrum has become the finest choice of organizations to deliver more value to the customers. In State of Scrum 2018 survey, 85 percent of the respondents say Scrum continues to improve the quality of work life. At the same time, 81% of Scrum Masters who received certification agreed that it has significantly helped improve their practice.Listed below are the reasons and benefits of having a Scrum Master certification (CSM).1. In-depth knowledge of Scrum:If you have not implemented Scrum before, earning the certification will help you to learn the Scrum skills effectively. With this certification, you can level-up your knowledge with the basics of Scrum and you will be able to:Make customers happy and satisfiedDeliver better quality product in less timeMaintain team collaborationLesser defectsFlexible working strategyTake a quick decision on an issue2. A number of companies moving to Agile:Nowadays, organizations are required to speed up their product development process to deliver fast according to the changing needs of the customers. This helps organizations to stay viable. Scrum produces in iterations and its self-organizing teams deliver products of maximum value. Due to this reason, a number of companies are shifting to Agile.      3. New career opportunities on the go:A CSM certification will bring more new career opportunities as more companies are migrating to the Agile approach and they need a professional who will guide a team to follow the Scrum approach. Being a certified Scrum Master, your chances of getting hired by the top employers with fair salary are more.    4. Increases collaboration:When it comes to working on a complex project, it needs collaboration among the team members. As a certified professional on a team, you can build and reinforce the basic understanding of Scrum to produce a value.  5. Switch to the Agile mindset:You need to develop an Agile mindset if you have to work with Agile methodologies. As a certified person on a team, you need to start thinking in an Agile way that will avoid differences in opinions and lead to successful projects with better team collaboration.    7. Organizations yield more:It is tough for any organization to accept new processes easily as it affects the complete structure of the organization. It affects processes, management, people, and clients. In this regard, you need a knowledgeable person in your team who will make the adoption a smooth process. Being a certified Scrum Master, you will be facilitating the tasks for the team members.  8. Enter the Scrum experts community:After taking a Certified ScrumMaster certification, an individual will get a chance to be a part of the Scrum experts community of Scrum Alliance. This community offers knowledge in a way to stay updated, find the events, and provide instructions to the certified members.Scrum Master vs. Project ManagerOnce we enter the industries, we often come across the term Project Manager along with the Scrum Master. These two roles are distinct from each other though they contribute to the projects. This creates confusion between the Scrum Master and Project Manager roles when an organization is undergoing an Agile transformation.A Scrum Master works on the Agile project associated with Scrum project management principles whereas a Project Manager’s work is based on the traditional disciplined project management principles. Let’s see the differences between a Scrum Master and Project Manager. Also, if you are serving as a Project Manager and willing to become a Scrum Master or vice versa, this information will help you to take a stand on this. Before going further, let's see the roles of the Scrum Master and Project Manager in brief.1. Scrum Master duties:Scrum Master responsibilities to the Product Owner (PO)-Helps the PO in managing the product backlogHelps the PO to convey the product requirement clearly to the team members  Facilitate Scrum events to the POScrum Master responsibilities towards the development team-Guiding and coaching the teams to follow Scrum rulesRemoves roadblocks that are inhibiting the project’s progressHelps to maintain team dynamics and high-value resultFacilitate the Scrum events and arrange Scrum meetingsDirecting the team in Scrum implementationMentor the team members who are new to Scrum adoption2. Project Manager roles:The Project Manager is responsible for:Delivering the product according to the project’s requirementsDefining the project scope and planning the project activities accordinglyEnsuring that the responsibilities assigned to team members are according to their skills and expertiseReporting the progress of the project to the stakeholdersTracking the project performance against the timelines and ensuring an effective project qualityMaking sure that the project documentation is properPlanning the tasks for the team members and ensuring that the team understands their roles in the projectPreparing a project budget and getting it approved from the senior managementManaging the StakeholdersMonitoring and controlling the risks in the projectDelivering the project on time with the project constraints like scope, the budget, time, and efficient resourcesLet’s figure out the major differences between a Scrum Master and Project ManagerScrum MasterAttributesProject ManagerMakes sure that the team members are well trained to follow Agile practices appropriately. Also, SM coaches the Scrum teams and mentions the timeline to finish the projectGoalsHas defined goals like-Completing the project on time, planned a budget, and scopeSM assures the quality and knows the importance of quality.Quality AssurancePM also knows the importance of quality, but doesn’t know how to achieve it. A consultant is usually hired to fix the errorsScrum Master always tries to keep things smaller. They like to work in small teams irrespective of budget.Team SizeProject Managers like to make things large. PM works with more people and a huge budget. In this way, they improve to Program ManagerThe average salary of a Certified ScrumMaster® is $116,659 per year.Average SalaryThe average salary of a Project Manager is $75,474 per yearCertified Scrum Master (CSM)®Advanced-Certified Scrum Master (A-CSM)®Certified Scrum Professional- Scrum Master (CSP-SM)®Professional Scrum Master (PSM I, PSM II, PSM III)Agile Scrum Master (ASM)Scrum Master Certified (SMC)SAFe® Scrum Master (SSM)SAFe® Advanced Scrum Master (SASM)CertificationsAgile Certified Practitioner (PMI-ACP)®Project Management Professional (PMP)®Certified Associate in Project Management (CAPM)®Certified Project Manager (IAPM)CompTIA Project+Certified Scrum Master (CSM)- Scrum AllianceAdvanced-Certified Scrum Master (A-CSM)- Scrum AllianceCertified Scrum Professional- Scrum Master (CSP-SM)- Scrum AllianceProfessional Scrum Master (PSM I, PSM II, PSM III)- Scrum.orgAgile Scrum Master (ASM)- EXINScrum Master Certified (SMC)- SCRUMstudySAFe® Scrum Master (SSM)- Scaled Agile Inc (SAI)SAFe® Advanced Scrum Master (SASM)- Scaled Agile Inc (SAI)Accreditation bodiesAgile Certified Practitioner (PMI-ACP)®- PMIProject Management Professional (PMP)®- PMICertified Associate in Project Management (CAPM)®- PMICertified Project Manager (IAPM)- International Association of Project ManagersCompTIA Project+- CompTIAEfficient Scrum Master = Great OrganizationThe role of a Scrum Master may vary from one project to another or one organization to another but the importance of Scrum Master in a team will always be the same. The role of the Scrum Master in general is very challenging. It goes without saying that hiring a Scrum Master is the wisest decision for an organization undergoing a real transition to Agile!  
Rated 4.5/5 based on 12 customer reviews
9903
Everything You Need to Know About Scrum Master

What is a Scrum Master?A deep understanding of Scr... Read More