I have to admit, as a Scrum Master, I struggled with this for a while, so I’m hoping it helps other Scrum Masters and teams out there get started.
If you are just starting out in Scrum and are not sure how to start running this meeting at all, or would like to update the way you are running it based on the November 2020 Scrum guide updates, then take a look on how you can have an effective Sprint Planning session.
- Time-boxed to 8 hours (for a month long sprint) — adapt to suit your Sprint length
- It must be the first thing you do in a Sprint. Usually held directly after Sprint Review, so that valuable feedback from that ritual can help adapt the plan for the future
- Required attendees: The whole Scrum Team; Scrum Master, Product Owner and the Developers
- Optional attendees: Anyone else that will help build a better plan
From the Scrum Guide:
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.
This ritual is split into 3 main parts:
- Why is this Sprint valuable?
- What can be done this Sprint?
- How will the work be done?
Why is this Sprint valuable?
I often find it’s best for the Product Owner to walk the team through the roadmap here; describing where we are heading as a team in the long term, what the next Product Goal is, and how the Sprint we are currently planning fits into all of that.
It helps create alignment and build a vision. Reminding us all why we are here, rather than getting lost in busy work.
We also start thinking about a Sprint Goal at this point; the whole team collaborates to define a Sprint Goal but the Product Owner usually comes along with a general idea that we build out.
Starting with the Sprint Goal early on allows us to choose items from the Product Backlog that suit that goal. We’ve often fallen into the trap of defining the Sprint Goal after the items are selected.
What can be done this Sprint?
From the Scrum Guide:
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
We come armed with recent team metrics and performance data; combine that with your teams capacity this Sprint and we should be able to develop a great plan.
Calculating your team’s capacity is as simple as asking “how much time can each of you commit to this team for the upcoming Sprint”. So ask if anyone is on holiday, are there any public holidays, do you have other commitments this Sprint which will take time away from Sprint work? Write that down and you have your team capacity.
When you are just getting started, I often find it best to start calculating team capacity in days; e.g. “I’m in for 10 days this Sprint”. As you get better at this, you might want to move to more specific hour-based planning e.g. “I’m in for 60 hours this Sprint”. This should help you build a more accurate plan. That’s something you can experiment with to see what works for you and your individual situation.
At this point, we have our historical team performance and our capacity for this Sprint, so next up we need to figure out what Product backlog items we can try to complete (subject to our Definition of Done).
You can proceed in one of two ways; velocity-based or commitment-based planning:
- Velocity-based planning is when you take the number of points you completed last Sprint (or some average over the previous n sprints) and you select items from the backlog that are approximately the same number of points— great for when you are just starting out
- Commitment-based planning is when you start with the item at the top of the Product backlog, break it down into tasks, and check in with everyone on the team whether they can commit to completing that one story. If everyone says yes, we move on to the next story and repeat the process until someone is “full” for that Sprint. At this point you can search for other stories that don’t require that person, or you simply stop)— commitment-based planning is my preference for more experienced teams
How will the work be done?
Regardless of which planning method you choose from above, it’s often best to break down each Product Backlog item into sub-tasks, each task describing how the work will be done. The team then estimates in units of time, each sub-task.
Each team member can then add up all of the estimates for all of the sub-tasks assigned to them to check it doesn’t exceed their total capacity for the Sprint.
To wrap up the Sprint Planning session, check with the team that they all support “the plan”. By the end of this ritual you should have completed the following:
- The whole team understands how this Sprint fits into the bigger picture and contributes to the next Product Goal
- The Sprint Goal should be clear to everyone
- Items that help satisfy the Sprint Goal have been selected from the Product Backlog and added to the Sprint Backlog
- The Sprint should be challenging, but achievable and the Developers should have selected the work based on what they believe they can complete in the Sprint; they are not dictated how much work to bring in by anyone.
The result of Sprint Planning is the formation of the Sprint Backlog:
From the Scrum Guide:
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.