Two methods of sprint planning in agile / scrum
Sprint planning in agile is one of the essential Scrum ceremonies and is absolutely vital to any team doing Agile software development with Scrum. Successful sprint planning gives a team a clear and realistic goal and a sensible pipeline of work. It also helps teams understand stories and their flow.
However, many teams get tripped on this important matter. How do we know how much work to put into the sprint? This is an important question but fortunately, it is not too difficult for a scrum team to answer.
There are two main approaches to figuring this out: Yesterday’s Weather and Fill the Bucket. I recommend an approach that involves a bit of both since they each have their advantages and disadvantages.
Why sprint planning is important
Spring planning is a crucial event in Scrum. There are three main objectives for a sprint planning meeting:
- decide on which stories will go into the sprint
- decide on the sprint goal
- and decide on the plan for how the work will be delivered.
The sprint goal usually becomes clear as the scope of work for the sprint is defined. I like to think of it as a summary of the stories defined for the sprint, in simple business language.
For example, if there are half a dozen user stories chosen that are all around user authentication, and that will effectively complete the authentication feature, then the sprint goal is “complete the user authentication feature”.
The plan for how the work will be delivered is up to the dev team (not the product owner!). Nobody can tell the development team how to deliver the user stories.
The plan usually involves clarifying the order in which the work will be done. And clarifying who might choose to start on which stories. Though remember: work should be “pulled” by someone from the sprint backlog rather than “pushed” onto them. It might also involve clarifying the architecture or development practices to be used.
This article will focus on the first objective though, defining the stories that will go into the sprint. Who does this and how should it be done?
How to select stories to go into a sprint in your sprint planning
Yesterday’s weather or fill the bucket?
There are two main techniques you can use to choose how many stories to put into a sprint in your sprint planning meeting: Yesterday’s Weather and Fill the Bucket.
Yesterday’s Weather
This is a simple way of forecasting the scrum team’s capacity for the upcoming sprint: just assume it is the same as last sprint. If your velocity was 50 points last sprint, then the team should assign 50 points worth of stories into the sprint that is just starting. Or if your points don’t add exactly up to 50, then put in less.
If you’ve put 48 points, and you only have a few 5 point stories in the backlog that are ready to be pulled, then leave them. It’s generally better to under promise and over deliver! This method has some advantages:
- It’s very easy to remember
- It’s very straightforward to apply
However, it has a disadvantage. If you have abnormal sprints (i.e. your previous sprint was unusually high or low), then your forecast will probably be off for the next sprint. However, it will usually rectify itself in one sprint’s time.
So for example, say your team normally does 40 points, then one sprint you had everything go right and you landed 80 points. Your forecast for this coming sprint will be 80, which you probably won’t achieve: let’s assume you did your normal 40 points. You will obviously not match the sprint goal, but your next spring planning you will be using 40, not 80 points as your guide.
Fill the Bucket
This method is different in that it doesn’t consider previous velocity when deciding how many points to put in the sprint. The team simply looks at the high priority Product Backlog items and starts moving them off and into the current Sprint Backlog. Each time a story is moved, the team considers and discusses whether the “bucket is full”, i..e could the team realistically take on more stories.
As more user stories are added to “the bucket”, it becomes more full. Until at some point, the team agrees that no more should be put in, i.e. they think they will not be able to deliver any more scope. There are some advantages:
- The team isn’t obliged to follow any particular velocity guideline
- The team can consider their current situation when deciding the sprint scope. E.g. they might want to not pull in many stories because there are some key people on leave this sprint. Or they might pull a lot more stories if some major blockers have been removed.
There is however a disadvantage:
- There is no initial guideline for how much scope to pull into the sprint, which might make it hard for the team to guess how much to put into the bucket.
Which sprint planning method is best?
I would recommend teams us a mix of the two methods. Start with Yesterday’s Weather (i.e. look at your last sprint’s velocity), discuss whether it is a realistic amount to use again for this sprint. Then start pulling stories into the sprint until the team feels that the bucket is full. It gives a clear starting point, but allows you to adjust based on other factors specific for that sprint.
Question: Have you used either of these methods, or another method? What experience did you have with it?
