Have you ever been in a sprint planning meeting that sucked? I have. Admittedly, I have found myself running a few too!
The worst sprint planning meetings I’ve experienced have all been down to a lack of preparation. In this blog post I will look at how the right amount of preparation makes sprint planning much less painful.
Give the backlog sufficient attention before the sprint planning
The product backlog needs a bit of tender love and care before the sprint planning. Not only will this make the sprint planning meeting run a lot quicker and smoother. It will also make it much more likely that we’re able to bring in the top items from the backlog into the sprint.
The most common way to do this is of cause to schedule a backlog grooming meeting during the sprint to look at what’s coming up in the next sprint or beyond. By scheduling such a meeting a week before the sprint planning meeting, there will be a bit of time to resolve any outstanding questions.
Involve the team in the preparation
It shouldn’t be down to just the product owner or business analyst to identify all the requirements and – even worse – create the solutions. There is a lot of expertise in the team, so make the best use of that. If we don’t, there is a good chance that what seemed like a perfectly good idea will be shot down in the sprint planning.
Exactly how we do this can take many forms and we need to find out what works for our team. One option is to include everyone in the grooming. As a bonus, people will be well familiar with the story by the time it gets to sprint planning. Another is to use a smaller group of people and maybe rotate the responsibility in the team. A third is to do some preparation first in a small group and then share the findings. We need to experiment to see what works best!
Make sure the stories are ready – but don’t take it too far!
What we strive for is to make sure we know enough about the story to be able to complete it in a sprint. Exactly what this means will vary from story to story, depending on how complicated it is.
In many cases, a short bullet point list of the acceptance criteria (and an estimate to make sure the story is not too big – break it down further if it is!) will be all we need. However, when the story is more significant, a bit more detail may be beneficial. This could for instance include basic sketches of the user flow or even mockups of a few key screens. Preparation could also include some technical investigations to understand what needs doing, to surface any dependencies etc.
It is a good idea to prepare a few more stories than is likely to fit into the next sprint. This way, if it for some reason turns out we are unable to start the top few stories, we will have other stories ready to pick up in the sprint planning.
However, make sure to not over-do the upfront specification work. The goal is to find out just enough so that the rest can be worked out in the sprint. For instance, requiring complete, signed off UX designs before something is brought into a sprint is an unfailing way to limit the agility in the sprint.
Have a good idea about the sprint goal before the sprint planning
Some teams consider their sprint goal to be the list of user stories they agree to bring into the sprint. While this is one way to identify what to do, it’s usually not the best one.
A good sprint goal helps create focus and make it clear why we are doing what we are doing. It will also allow a bit of flexibility. One such goal might be “Create a first version of the shopping basket, to allow a round of user testing”. It’s clear what we’re doing and why. If we start running out of time in the sprint, we can adjust the stories in the sprint, while still achieving the goal. “Do we really need discounts right now?”
Trying to construct such a goal from a random selection of stories can be very difficult. “Complete all the stories in the sprint” doesn’t count as a sprint goal! One way to try to avoid mixed bag goals like these is for the product owner to have a good think about what would be a good outcome of the sprint beforehand. What is the most valuable thing we can do right now? All those other things, while they might be urgent, are they really that important?
This doesn’t go to say that the product owner gets to decide on their own what the sprint goal is. Only the team can decide how much work to bring into the sprint. The sprint goal agreed between the product owner and the team at the end of the planning meeting may therefore end up being something slightly (or sometimes completely!) different than the initial goal.
Make sure to have the details at hand in the planning meeting
One small but oh so important bit of preparation is to make sure that the outputs from the discussions we’ve had so far are readily available to look at in the sprint planning meeting. I prefer simple tools, so I like to fold print outs and sketches and attach them with a paper clip to the index card of the story they relate to. The equivalent when using an issue tracking system like Jira is to link or attach all relevant bits to the ticket.
.Whichever way we choose, avoiding digging around on network drives and wikis will make the sprint planning meeting run a lot smoother.
The Scrum Guide allows a generous eight-hour timebox for planning a one-month sprint. That is enough time for most people to rather poke a fork in their eye!
With the right preparation, the sprint planning meeting can and should be reasonably quick.
Mainly, all we want to do in the meeting is to agree a goal and create our sprint backlog. Most of the stories will already be well-formed and estimated. We’ll also have made sure we have all the necessary information at hand to clearly and quickly explain each story. Unavoidably, there will be some adjustments needed, not least following the sprint review, but hopefully nothing too taxing.
I realised while writing this blog post that I must have been in about 300 sprint planning meetings by now. In my experience, two hours tends to be about right for a two-week sprint. One hour for going through the stories and then another hour for the task breakdown. Don’t take my word for it, though. Experiment and see how much time you need!