How to Achieve Perfect Sprint Planning
This title is a misnomer as perfection is a fallacy, and there’s no such thing as perfect. So instead of focusing on perfection, let’s focus on ‘good enough’ because ‘good enough’ is achievable.
What is Sprint Planning?
Sprint Planning is a ceremony in the Scrum framework in which the Sprint Team plan out the upcoming sprint. The purpose of Sprint Planning is to plan the tasks against the capacity of the team over the Sprint, with the aim of the Sprint to deliver value. There’s a lot of philosophy around Sprint Planning, which I encourage everyone to familiarize themselves with – as it expands on the purpose written above.
How do we achieve ‘good enough’?
Scrum provides structure for communication between the various interested parties in an organization, whether they’re the delivery team, the end users, a sponsor, or someone curious in what’s happening.
Every single ceremony in the Scrum framework is centred around transparent communication and how what is being delivered is providing the expected value in each iteration. Sprint Planning is no different.
With the aim of Spring Planning being to provide iterative value, as well as understanding what can be achieved in the allotted timeframe, the Product Backlog is the central artefact in facilitating that aim.
Just Enough Detail
Before each new Sprint starts i.e., before Sprint Planning, each candidate user story must have enough detail in their description and acceptance criteria in order to facilitate meaningful discussion. Coupled with that, each candidate user story must be reviewed ahead of Sprint Planning by every member of the team, again to facilitate meaningful discussion.
When I say meaningful discussion, it’s really so that the team fully understands what they’re delivering, how they’re going to deliver it, and, more importantly, why they’re delivering it. We want to avoid situations where members of the team are saying things like:
- There’s not enough detail!
- I don’t want to read War & Peace to understand this!
- What value does this story provide?
- Haven’t we already delivered something like this?
What ‘enough detail’ looks like will vary between teams, and it’s important that, as a team, you find out what works for you. Fully expect your first few Sprint Planning sessions to be messy and chaotic as everyone finds out how they like to work and communicate together. There’s no one-size-fits-all approach, nor is there any tailoring – you’ve got to find this out for yourselves.
Setting Expectations
Once we’re in Sprint Planning, we want to start with the goal – what are we trying to achieve in the sprint; what value are we trying to provide? The goal is presented by the Product Owner to the team. The team then sets their capacity for the coming Sprint, which will have an impact on the feasibility of the goal.
Time to discuss and estimate the candidate stories, one by one, in order of priority. The user story should be presented by the Product Owner to the team. This presentation, because the team will have reviewed the candidate stories beforehand, will prompt discussion – particularly from an implementation perspective. Be sure to capture the potential tasks that come out of this discussion.
Discussion exhausted and tasks fleshed out? Get your poker face on and estimate those tasks. Planning poker is a useful exercise because it allows for quieter voices in the room to be heard without being influenced by louder voices. It also allows for further discussion – particularly if there are wide deviations in the estimates. Perhaps the expectations or understanding of a task are not aligned? Perhaps there’s a skills gap and someone needs support to deliver the task? With each task discussed, add the discussion points to the task. Once the team agrees on the estimate, move on to the next task until all the tasks for a story have been estimated.
Then repeat the process with the next story, and the next, until there is no more capacity left for the sprint.
Will the goal be met? The user stories should reflect the goal, but the goal may need to be adjusted or the sprint length adjusted for the goal to be realized. This is really at the discretion of the Product Owner in consultation with the team, but rule of thumb guidance is to adjust the sprint length as a last resort.
There is no set time frame for how long Sprint Planning should take as it needs to last however long it takes for the session to be effective. This could be an hour; it could be 8 hours. Until the capacity for the sprint has been filled with value driven user stories, and the sprint goal reviewed, the planning session isn’t over. If you’re new to Scrum and the concepts of sprints, having an initial meeting for 2 hours per sprint week is a good starting point, so a 2-week sprint’s planning session would last for 4 hours, and a 4-week sprint would have an 8-hour planning session.
Sprint planning done – time to communicate the goal and the expectations to the wider group, the interested parties who will be keenly interested in how the sprint goes and will review the work done in the sprint review.
Iterate
Scrum and other Agile frameworks are iterative. The Sprint Planning process itself is iterative and will continuously adjust to what works well for you, so long as you keep on communicating with each other. There is a process to follow, but the process is not prescriptive – it is principle driven. Communicate, learn, iterate, grow, improve. What is written above is advice that may or may not work for you – but use it as a starting point and iterate until you find a style that works for you. It will take many iterations to get there, but once you get there you’ll be in a great rhythm that will be good enough but will feel perfect.