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.
Spring planning is a crucial event in Scrum. There are three main objectives for a sprint planning meeting:
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?
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.
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:
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.
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:
There is however a disadvantage:
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?