Search

Series List

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 164
  • by Steve Ash
  • 08th Oct, 2018
  • Last updated on 10th Dec, 2018
  • 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

Agile Contracts or Agile Statement of Work - Must-Haves

In IT with the Agile boom, everyone wants to get into Agile Development. Be it the customers, organizations, and even developers, everyone wants to get into Agile Development. Customers want to follow Agile so that they can get to see the Product early and the changes can be incorporated without any cost. In other words, they want fixed price, variable scope. But, organizations need to be cautious in order to define how much variable scope is included in contract clauses. Organizations want to keep themselves up-to-date and follow Western culture blindly. Statements like these often come “Everyone is going Agile, why aren’t we yet?” They have to understand, every environment, every team, and every client is different. We just cannot keep on copying everyone else. Developers, of course, will have “Agile” word in their resumes which will help them grow and find jobs.   The number of agile contracts [by govt] amounts to a coat of agile paint on a giant waterfall HT @RachelProsser https://t.co/IEOPRRFFM5 — (((Dave Moskovitz))) (@davemosk) October 9, 2017 So, in desperation, companies (small or medium organizations) ONLY follow what customers say. What they end up is – with an agreement that has clauses of Waterfall model and they tell clients that we will follow Agile. These clauses might be like having fixed scope or fixed price which will be given by end of phase like requirement gathering or planning or UAT done etc. But we forget, that in Agile, every iteration has these phases and we should be targeting the contract in such a manner that it is win-win for both the parties at end of every iteration. Below figure distinguishes between the Traditional Pyramid and Agile Pyramid. Traditional pyramid has fixed scope while Agile one has the Estimated scope, to be considered while negotiating the contract.   Lawyers and Sales team need to be taught that if we are following Agile, we need to follow the terms and conditions for Agile contracting and not of Waterfall.   #agile contracts, however, are not the silver bullet: few of them delivered the right client benefits. @WC_REFSQ pic.twitter.com/8MSb0okXQ7 — Samuel Fricker (@samuelfricker) March 15, 2016 Apart from including changes like, Product Backlog (instead of BRD), Key roles in Project, the Agile methodology, below are few MUST HAVES that should be mentioned clearly in the contracts and need to be communicated to the customers, during the contract negotiation: 1. Pricing Model: It is unrealistic to expect any development project or product, to be delivered on a Fixed price basis. We all know that there will ALWAYS be changes in scope which will affect the original price. If the customer has a fixed budget, this can be managed within an Agile project by focusing on the development of high-priority items first, allowing the Customer to remove low-priority items from scope. All such issues must be taken into account when negotiating the Pricing Model for the project. Below are a few potential pricing models: a. Fixed Price per user story – Be cautious here, too long user stories need to be broken up.  b. Fixed Price per iteration – Make sure that all iterations range to similar story points. Remember, we have to create win-win for both parties. c. Fixed Price for the agreed number of features – Describe the feature well in advance. d. Time & Material (our favorite) - Customer continues to pay during an agreed-upon time period. The customer pays till a point he sees value being added. In case he sees that no value is being added, the customer stops paying and the contract ends. 2.Spikes for high-risk elements: In case the project has specific, high risk elements, e.g. technical challenges or business issues that are absolutely first timers or have never been solved before, these MUST be communicated up-front. Such Programming spikes where we attack only the riskiest coding in the project must be included in the contract. These spikes give customers a realistic view of the project ahead for the least amount of money and avoid conditions of "Fast failure". The main goal here is to uncover any weaknesses in the proposed development and hence be ready with the new plan and strategy in order to make the project successful. 3. Define Scope, but no need to mention delivery items: Product backlog defined at the high level MUST be attached to the contract as one of the appendices. Though the scope is variable and will change during the course of the project, high-level scope must be included in the contract. Delivery Items will change post discussion with PO on every iteration, but the high-level scope remains the same. Emphasize on process rather than on dates and items. This will keep the team’s mindset collaborative. 4. Settle on Definition of Done at high level: While negotiating the contract, the “Definition of Done” should ideally be defined and attached as an appendix. The clauses for “Definition of Done” that needs to be included are: a. During every Sprint Planning, PO and the development team will review the “Definition of Done” for the items that are included in that particular Sprint. b. In case of disputes, there should be appropriate resolution techniques in place between the parties.   Concluding the article by revisiting one of the values of Agile Manifesto: Customer collaboration over contract negotiation. Contracts matter to those who have signed it. Customers do face problems and you will be able to see them only when you talk to them. Once you see and understand their problems for which they have hired you to provide the solution, you need to COLLABORATE with them and get to it. Despite all the clauses in the contract, the motto should be “LET’S DO IT !!”.  
Rated 4.5/5 based on 1 customer reviews
1139
Agile Contracts or Agile Statement of Work - Must-...

In IT with the Agile boom, everyone wants to get i... Read More

Definition of Done (DoD): Why & How To Use It In Agile Project

Definition of Done (DoD) is the collection of deliverables like writing codes, coding comments, testing of units, integration testing, design documents, release notes etc that add verifiable and demonstrable values to project development. DoD helps the Scrum team to identify all the valuable deliverables needed to complete the Agile project successfully on the time. Although ‘Definition of Done’ is the fundamental element of Scrum methodology; yet, a number of Agile-Scrum teams neglect its importance. The blog post spills the beans on ‘why & how to use DoD in Agile project’.  Why to use DoD in Scrum Project:    DoD Helps To Get Feedback For Improvement:   DoD defines all the steps to deliver an increment; therefore, it helps Scrum team members get feedback about the product and processes. The well-defined steps like sprint demo, acceptance testing, functional testing etc generate on the time feedbacks from the product owner. The more detailed Definition of Done helps you get more feedbacks. Definition Of Done (DoD) Improves Planning To Release At the end of sprints, numbers of processes or tasks are found incomplete at one stage or the other; gradually, the undone work piles up to retard the Agile project’s progress.  The application of DoD helps to complete all the undone work within the particular sprints; thus, saves valuable time because you do not need release sprints. Definition Of Done Elaborates Burn-Down Charts In True Colors:    If DoD is not applied, Agile burn-down chart, the  graphical representation of work still to be done, often presents false image of ‘when the software will be production ready’ because it doesn’t account the undone work accurately at sprints. As a result, the undone work piles up in hidden way while the burn-down chart shows the reduction in remaining work. The burn-down charts created with DoD application presents real picture of work done in complete.    Real Value of a #Definition of #Done in #Agile - http://t.co/dN8laZqIRQ Improve your #product, process @ScrumAlliance pic.twitter.com/HcI4P8eunb — Synerzip (@Synerzip) 2 June 2015   Definition Of Done Minimizes The Delay Of Risk: ‘Definition of Done’ helps you minimize the delay possibility because the defined steps in DoD generate on the time feedbacks guiding you to manage all the identified risky items by inspection, adaptation and improvement at an early stage.  DoD Reflects The Agility, Maturity & Quality of Scrum Team: The efficient Scrum team is expected to complete a new feature in single sprint and to release it at the earliest with guarantee of being the best. DoD reflects the agility, perfection, maturity of Scrum team by exhibiting that it releases new feature in every sprint. How to Use DOD in Scrum: 1.Make DOD Essential: To complete the project on the time, make it essential to follow DoD in each sprint review. Walk through DoD for each PBI (product backlog item) to make it “front & centre” for the team members and stakeholders; it will establish perfect understanding with mutual trust between the project development team, product owner and other stakeholders.  2.DoD Checklist: Use DoD as a checklist for each PBI. Only after going through the complete checklist up to the satisfaction, proceed for the next step.   3.Make DoD the Tasks Oriented:  Create a specific task for each DoD element to ensure that you are more focused on DoD items.  Tasks are easier to manage by managing the expanded DoD checklist.  4.Involve PO to Review DoD at Mid-Sprint:  Develop the culture of showing PBI to PO during mid-sprints. It facilitates PO to know about DoD status.  5.Apply  DoD with Retrospective Approach:  Always be ready to improve, and explore the possibility to make the processes more robust. Ask other Scrum teams for innovative concepts that helped them; and, explore the suitability of shared tips in the line of your project.  Conclusion:  The major reason to adapt anti-DoD pattern is lack of awareness about the importance of DoD.  In most cases, whenever DoD is neglected, it bites the project’ progress & quality. Agile and Scrum training helps the project team members to understand the importance of DoD and the strategies to apply it. Therefore, do not take chances, and, use ‘Definition of Done’ as a Scrum tool for improving quality, minimizing delay possibility and building trust with all the stakeholders.
Rated 4.0/5 based on 5 customer reviews
Definition of Done (DoD): Why & How To Use It In A...

Definition of Done (DoD) is the collection of deli... Read More

Scrum Master and Product Owner: Understanding the differences

 Agile methodology imparts the easy and convenient path to work. Scrum is one of the famous Agile methodologies. Agile methodologies consists of 4 main roles, viz. Product Owner, Scrum Master, Scrum team and Stakeholder. Each role has its share of responsibilities. These roles are all about commitment. Scrum master and the Product owner are two vital roles in the Scrum Software Development Methodology. Since they both are working on different areas of the project, they are indispensable for the project. Scrum Master is a mediator between the Product owner and the Development Team.       Product Owner vs Scrum Master- Though the Product Owner and the Scrum master vary in their roles, they complement each other. Scrum master should support the product Owner in every step possible. There should be an amicable relationship between the Product owner and the Scrum master. Disputes may happen between them if the roles are not clarified. Let us have a look at the differences in roles between the product owner and the scrum master. The Scrum Master concentrates on the project success, by assisting the product owner and the team in using the right process for creating a successful target and establishing the Agile principles.    Scrum Master Skills (SM): SM creates a friendly environment for the team for Agile development. SM improves the quality of the product. Certified Scrum Master Certification, adds advantage to become effective. SM protects his team from any kind of distraction and allows them to stay tuned. SM helps product owner to maximize ROI (return on investment) to meet the objectives. SM removes disputes between the product owner and the development team. SM encourages the team to meet the project deadline. SM acts like a coach for a team to perform better. A good Scrum Master should possess the skills like project management, engineering, designing, testing background and disciplines. SM provides continuous guidance to teams   Duties of Scrum Master: SM facilitates team for better vision and always tries to improve the efficiency of the teams. SM manages Scrum processes in Agile methodology. SM removes impediments for the Scrum team. SM arranges daily quick stand-up meetings to ensure proper use of processes. SM helps product owner to prepare good product backlog and sets it for the next sprint. Conducting retrospective meetings. SM organizes and facilitates the sprint planning meeting. The Product Owner’s responsibility is to focus on the product success, to build a product which works better for the users and the customers and to create a product which meets business requirements. The product owner can interact with the users and customers, stakeholders, the development team and the scrum master.   Product Owner Skills (PO): PO should have an idea about the business value of the product and the customers’ demands. Certified Scrum Product Owner Certification (CSPO) will be beneficial for the sales team. The development team consults PO, so he should always be available for them to implement the features correctly. PO should understand the program from the end-user point of view. Marketing is discussed on the sales level in most of the Organizations. So it is the PO’s duty to guide the marketing persons to achieve the goals successfully. PO is responsible for the product and the ways to flourish a business. PO has to focus for the proper production and ROI as well. PO should be able to solve the problems, completing trade-off analysis and making decisions about business deliverables. After CSPO course, PO can work with the project managers and the technical leads to prioritize the scope for product development. Sometimes PO and the Customers are same, sometimes Customers are thousands or millions of people.   Duties of the Product Owner: PO has to attend the daily sprint planning meetings. PO prioritizes the product features, so the development team can clearly understand them. PO decides the deadlines for the project. PO determines the release date and contents. PO manages and creates the product backlog for implementation, which is nothing but the prioritized backlog of user stories. PO defines user stories to the development team. Spending some time to prioritize the user stories with few team members. One can enhance his/her knowledge in many directions and beyond boundaries, after undergoing the Certified Scrum Product Owner (CSPO) training.
Rated 4.0/5 based on 1 customer reviews
3676
Scrum Master and Product Owner: Understanding the ...

 Agile methodology imparts the easy and convenien... Read More