Search

Agile 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.

How Not to be Agile – Ultimate Guide to Sprint Planning

555
  • by Steve Ash
  • 08th Oct, 2018
  • Last updated on 11th Mar, 2021
  • 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

Differences Between Certified SAFe® Agilist(SA) vs Certified SAFe® Practitioner(SP)

Business Agility can be defined as the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative, digitally enabled business solutions. As organizations strive to achieve business agility, they find they are quickly outgrowing small-team Agile and need to decide on an approach to scale to the enterprise. Scaled Agile Framework (SAFe®) for Lean Enterprises is a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps. It has several levels to which one can scale from Essential to Full SAFe®.Due to its scalability and its number of roles and ceremonies, companies are increasingly expecting team members to not only be trained in SAFe® but also become certified. Since SAFe® is the most popular form of Scaled Agile, it is wise to consider becoming certified in this framework. This article will compare and contrast two certification - Certified SAFe® Agilist (SA) vs Certified SAFe® Practitioner (SP). Please note that you cannot ‘test out’ for either of these certifications but must attend classes.Certified SAFe® AgilistThis is the certification that I acquired when I first started venturing into SAFe®. My certificate says “A Certified SAFe® 5 Agilist (SA) is a SAFe® enterprise leadership professional who is part of a Lean-Agile transformation. Key areas of competency include the application of Lean-Agile principles, execution and release of value through Agile Release Trains (ARTs) and building an Agile portfolio with Lean-Agile budgeting.” So, while it is a very good entry point and covers SAFe® thoroughly, there is no specific prescribed role other than ‘leadership’ and being part of the team, especially one involved as part of a Lean-Agile transformation.PrerequisitesLeading SAFe® /SAFe® Agilist Certification Course; 5+ years’ experience in software development, testing, business analysis, product, or project management; experience in Scrum. Leading SAFe® is a two-day course. Prices vary but they tend to be less than $1,000 USD. Attendees discuss how to establish team and technical agility and organize and re-organize around the flow of value. There are also exercises for supporting a key ceremony called PI Planning. Students also begin to understand how to implement a Lean Portfolio Management function in their enterpriseKey areas of competencyApply SAFe® to scale Lean and Agile development in the enterprise Apply Lean-Agile Mindset and principles Plan and successfully execute Program Increments Execute and release value through Agile Release Trains Build an Agile portfolio with Lean-Agile budgeting Exam detailsIn the author’s experience, the exam is difficult but not as difficult as, for example, the Project Management Professional® exam. Some questions may be situational but overall, they want to ensure that you understand the framework and its underlying principles.  The exam can be taken any time after the class is completed but ideally should be taken within 30 days. It is a non-proctored, closed-book, multiple-choice exam which can be accessed on-line within the SAFe® Community Platform.  Candidates have 90 minutes (1.5 hours) to complete the exam. There are 45 questions and passing score is 77% or 35 correct. Currently the exam is only provided in English. The first exam attempt is included as part of the course registration fee if the exam is taken within 30 days of course completion. Each retake attempt costs $50 USD.  Retake policy – Second attempt on exam (first retake) can be done immediately after the first attempt. The third attempt requires a 10-day waiting period. The fourth attempt requires a 30-day waiting period. (It is not unusual for companies providing such exams to impose longer waiting periods if you fail. They want to give you more time to study.) Sample questionSeveral sample questions are provided online by Scaled Agile Framework. This is a typical SA question from their pool: What does SAFe® Principle #3, "Assume variability; preserve options," enable? Specification traceability Better economic results Stronger Definition of Done Up front design of systems The answer is ‘Better economic results.’ Exam study materialsCourse materials – The course materials are an essential artifact from the course and can be downloaded from the SAFe® Community Platform. Study guide – This guide details the job role and all resources related to the exam, including a detailed reading list. Access is available through the Learning Plan in the SAFe® Community Platform upon course completion. Practice test – The practice test is designed to be predictive of success on the certification exam and it has the same number of questions, level of difficulty, and time duration. It is part of the Learning Plan in the SAFe® Community Platform and can be taken an unlimited number of times at no cost. This is not the actual exam and passing it does not guarantee success on the certification exam. Sample Questions – A web-enabled, flashcard style version of the sample questions can be found online and in the study guideWhat you getCertification includes: Certified SAFe® Agilist PDF certificate. Certified SAFe® Agilist digital badge to promote your accomplishment online. One-year membership to the SAFe® Community Platform, which includes access to the SA Community of Practice. Access to Meetup groups and events that connect you with other SAFe® certified professionals. A variety of learning resources to support you during your SAFe® journey. Certified SAFe® Practitioner (SP)The SA certificate is not designed for any specific role but is more foundational. The SP certificate provides the skills needed to become a high-performing team member on an Agile Release Train (ART) and collaborate with other teams. As with the SA certification, you must first attend a two-day course. You cannot ‘test out.’ Certification expires one year from the date it is earned.  Attendees also learn how to write user stories, plan and execute Iterations, and experience a PI Planning event. Attendees learn about the Continuous Delivery Pipeline, the importance of a DevOps culture, how to effectively integrate with other teams on the ART, and what it takes to continuously improve. Key areas of competencyExplain SAFe® Agile Principles Plan Iterations Plan Program Increments Execute Iterations and demonstrate value Improve Agile Release Train processes Integrate and work with other teams on the Agile Release Train Perform as a member of an Agile Team on an Agile Release Train Prerequisites:SAFE® For Teams two-day course; familiarity with Scrum, Kanban, and XP; familiarity with Agile concepts and principles; working knowledge of software or hardware development processesExam detailsThe exam can be taken any time after the class is completed but ideally should be taken within 30 days. It is a non-proctored, closed-book, multiple-choice exam. It can be accessed on-line within the SAFe® Community Platform.  Candidates have 90 minutes (1.5 hours) to complete the exam. There are 45 questions and passing score is 77% or 35 correct. Currently the exam is only provided in English. The first exam attempt is included as part of the course registration fee if the exam is taken within 30 days of course completion. Each retake attempt costs $50.  Retake policy – The second attempt on exam (first retake) can be done immediately after first attempt. The third attempt requires a 10-day waiting period. The fourth attempt requires a 30-day waiting period. Sample questionSeveral sample questions are provided online by Scaled Agile Framework. This is a typical SA question In SAFe®, which two items belong in the Team Backlog? (Choose two.)   User Stories Enabler Features Epics Spikes Tasks The answer is user stories and spikes. A spike’s purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.Exam study materialsCourse materials – The course materials are an essential artifact from the course and can be downloaded from the SAFe® Community Platform. Study guide – This guide details the job role and all resources related to the exam, including a detailed reading list. Access is available through the Learning Plan in the SAFe® Community Platform upon course completion. Practice test – The practice test is designed to be predictive of success on the certification exam and it has the same number of questions, level of difficulty, and time duration. It is part of the Learning Plan in the SAFe® Community Platform and can be taken an unlimited number of times at no cost. This is not the actual exam and passing it does not guarantee success on the certification exam. Sample Questions – A web-enabled, flashcard style version of the sample questions can be found online and in the study guide. What you getBecoming a Certified SAFe® Practitioner (SP) is an important step towards becoming part of a SAFe® team. Certification includes:  Certified SAFe® Practitioner PDF certificate Certified SAFe® Practitioner digital badge to promote your accomplishment online One-year membership to the SAFe® Community Platform, which includes access to the SP Community of Practice Access to Meetup groups and events that connect you with other certified SAFe® professionals A variety of learning resources to support you.Which certification should I choose?There is no one ‘right’ answer to this. Not all students are the same. When the time came to learn more about SAFE®, I asked myself the same question. Since I wasn’t seeking a specific role within a SAFe® team but was trying to attain a broader understanding of the framework, the SA certificate was sufficient, at least as an entry point. I found it gave me an excellent overview of the framework and I would feel poised to work in a SAFE® environment. However, if your goal is to be an active part of a team, it would appear that the SP certification might be the better choice as that is its primary focus.  Maintaining certificationYou can no longer renew your certification on an individual level. As of January 2021, Scaled Agile has moved to a membership model for the SAFe® Community Platform. With this transition you will now be able to renew your membership at one of three tiers, two of which will include a bundle renewal of all your SAFe® certifications. If you don’t need or want to include renewal of your certifications, you have the option to simply renew your membership to continue access to all the assets, tools, and resources to help you grow as a SAFe® professional.  The three Membership tiers are:SAFe® Program Consultant Membership ($895/year) - For members who currently hold SPC or SPCT certifications. Renews all certifications, provides access to all SAFe® content, and enables SPCs/SPCTs to train others to lead a Lean-Agile transformation. Certified SAFe® Membership ($295/year) - For members who currently hold one or more certifications, and who may benefit from a bundled pricing approach. Renews all certifications except SPC and/or SPCT, provides access to basic and some advanced content and continued access to course learnings and assets. Individual SAFe® Membership ($195/year) - For those who don’t seek certification but still benefit from the valuable content on the SAFe® Community Platform. No certification renewals included. Comparison tableSASPLearners are in these rolesCEO, Project Manager, Scrum Master, Team Lead, Release Train Engineer, Product OwnerProject Manager, Scrum Master, Team Lead, Release Train Engineer, Product Owner, Consultant, Agile Coach, Business AnalystTopics coveredThriving in the Digital Age with Business AgilityBecoming a Lean-Agile LeaderEstablishing Team and Technical AgilityBuilding Solutions with Agile Product DeliveryExploring Lean Portfolio ManagementLeading the ChangeIntroducing the Scaled Agile Framework (SAFe®)Building an Agile TeamPlanning the IterationExecuting the IterationExecuting the Program IncrementPracticing SAFe®What attendees getAttendee workbookPreparation and eligibility to take the SAFe® 5 Agilist (SA) examOne-year membership to the SAFe® Community PlatformAttendee workbookPreparation and eligibility to take the SAFe® 5 Practitioner (SP) examOne-year membership to the SAFe® Community PlatformPrerequisitesHighly recommended: 5+ years’ experience in software development, testing, business analysis, product, or project managementExperience in ScrumHighly recommended: Familiarity with Agile concepts and principlesAwareness of Scrum, Kanban, and XPWorking knowledge of software and hardware development processesExam detailsCompletion of this course gives you access to the exam and all related study materials as part of your Learning Plan in the SAFe® Community Platform.Completion of this course gives you access to the exam and all related study materials as part of your Learning Plan in the SAFe® Community Platform.Professional Development Units & Scrum Education UnitsConclusionThe Scaled Agile Framework is by far the leading approach towards scaling Agile. There is a variety of roles and certifications available. Both the SA and SP certificates will prepare you to enter the Scaled Agile world. It really depends on what you are looking to accomplish/learn from your course and what perspective you are learning from.To summarize, SA is a good foundational course if you are an individual new to SAFe® learning. SAFe® for Teams (SP) course is an intermediate level course that helps team members and SAFe® teams better understand how to work together to accomplish work and project goals. So, if you expect to be a member of a team involved in Release Trains and PI Planning, SP may be the logical starting point on your SAFe® journey. 
Differences Between Certified SAFe® Agilist(SA...

Business Agility can be defined as the ability to ... Read More

The Ultimate Guide to Sprint Planning

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

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

6 Metaphors To Understand The Value Of Scrum Values

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

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

Useful links