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

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.

Looking to become a project management expert? Our online PRINCE2 foundation training is the perfect way to achieve mastery with ease. With our expert-led program, you'll gain the skills and knowledge needed to become a certified PRINCE2 practitioner and take your career to new heights. Enroll now and start your journey towards success!

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.