Using Sprint Planning in a Scrum team

The start of each iteration is a planning event.  Sprint Planning (as it is called in Scrum) is focussed on converting the ordered product backlog into a specific plan for the next iteration.  Scrum calls this iteration plan a Sprint Backlog.  A key part of making iterations work is making Sprint Planning work effectively. This can be considered part of the “heartbeat” of the Scrum approach.

A potential for confusion there. This is not the same list as the main Product Backlog. The Sprint Backlog lasts only for the duration of the Sprint and is not ordered. It does however conform to the “backlog” concept of being fuel for the team.

Sprint Planning or Backlog Refinement?

Agile is often caricatured as having no planning.  Having done several reviews of classical and Agile environments, I would say that very similar amounts of time are spent on planning.  In a classical environment the planning is weighted to a small number of people at an early phase of the project.  While in Agile, the planning is more distributed and continuous.

A critical point to realise is that you cannot do all of your planning in this one meeting.  One of the biggest errors made by new adopters of Scrum is to see the word “Planning” in “Sprint Planning” and believe that is where all of the planning sits.

Trying to cram all the planning into the Sprint Planning event is never going to be successful.  The key planning process is not really this one at all.  Successful iteration requires a well ordered backlog.  And the backlog must have rightsized items at the top, ready to be executed. This all happens through Backlog Refinement.

The key planning process is Backlog Refinement

What is Sprint Planning?

Inexperienced teams will often try and refine Product Backlog in the Sprint Planning meeting.  There’s just not time to look across the whole backlog.  Sprint Planning is only about building the Sprint Backlog from the Product Backlog, the list of work which will be done during the Sprint.

When I describe it like that, Sprint Planning seems almost pointless.  Image you already have an ordered, decomposed list of work. All the top items are rightsized and ready to work on. They all pass the “Definition of Ready”. If so, why do you even need a meeting?  Does creating a Sprint Backlog add value? Why not just draw a line on the Product Backlog and saying “we will get this far?”.

What then is Sprint Planning adding that Backlog Refinement is not intended to do.

Sprint Goal

Scrum advises a Sprint Goal.  Something that the team will focus on for this Sprint.  It’s a clear outcome which the team can see as a mission to help the team collaborate. Rather than just collect work items, the team will work better with a goal. This will also help them make decisions and priority calls as they use the Daily Scrum to steer delivery.

Discussion

Rather than just take the top items on the Product Backlog the team should (briefly) review these.  There are many questions which can be asked.

• Does the team understand what these items are? 
• Are they really “Ready” and in a good state to start work – clearly described and well sized, with acceptance tests? 
• How do they align with the Sprint Goal – are they part of moving this forwards, or are they independent work?
• Should items a little further down the backlog be prioritised because they align better with the Sprint Goal or because they fit together technically?
• Has new work arisen from Sprint Retrospective or Sprint Review which should be considered?
• Where the backlog work is for reducing technical debt is everyone agreed on the urgency?

This is where involvement from the Product Owner to give immediate feedback in discussion is critical. The whole team should ensure that there is alignment about what is the best set of objectives for the Sprint.

Breaking down

The team will also look at how they will achieve the work.  On the Product backlog, items have a high level description.  In the Sprint backlog, more clarity may be needed. The team need to give a bit more thought about how they will be done and who will do them.  They may need some level of task breakdown.  And as part of this they will get a clearer estimate. This allows the team to agree what is a reasonable content for the Sprint.

The Sprint Backlog

The end result is that the Sprint backlog will mostly align with the top of the Product backlog.  There may have been a few items which the team aren’t able to start.  There may be a few items which were moved up the list because they aligned well with the Sprint Goal. 

The more continuous discussion there has been around Backlog Refinement, the more the two should align and the shorter the Sprint Planning meeting is likely to be. Ideally this is a confirmation not a surprise. In the Play about not using iteration, I suggest that a more experienced team works more continuously.

The Sprint Backlog is not a deterministic plan. We are still in a complex environment. Backlog items still have limited definition. However, if they are rightsized, there will be a level of predictability which makes Sprint level planning effective and worth the investment. There may be some items not completed. There may be some items added (although this should be avoided if possible). As a rough rule on predictability, I would suggest that a team should be able to achieve at least 80% of the planned Sprint Backlog.

Good practices

Good Sprint Planning does not just happen. As and Agile leader you should be prepared to coach teams in what “good” looks like. This may be an area worth investing in training, as it will probably pay dividends.

Make sure that the teams include all of the areas which might need work. Technical Debt reduction needs to be included as do proposals from retrospectives, as well as feature work. It is often worth tracking the time the teams spend on these non-feature items to ensure they are sufficient.

Try and ensure that the teams achieve around 80% of the Sprint Backlog or higher. This matters for a key reason. If the team pulls too much work into the Sprint they will lose focus. Remember that the Sprint Backlog is not ordered. If the team only complete half the work they have little guidance of which half. Those discussions are best occurring up front in Sprint Planning to make sure priorities are clear.