What is Sprint Planning?
Does a Scrum Team really need to plan the whole Sprint in the beginning? What should be the output of this Scrum Event? What is Sprint planning? In this vlog, I’m going to go over what the Scrum Guide definition is and what that all really means to you.
Sprint planning kicks off a Sprint by laying out all the work that the Scrum Team is going to accomplish for that Sprint. The resulting plan is created by the collaborative work of the entire Scrum Team. The Product Owner comes armed with information to make sure that everyone there understands how the work maps to the Product Goal. The Scrum Team may also invite others to participate if they have information that will help with Sprint planning; this might include your key stakeholders.
Sprint planning addresses the following topics:
Topic One: Why is this Sprint important? So the entire Scrum Team is going to craft a Sprint Goal. It’s the purpose of the Sprint. The Product Owner is going to come with information about why the upcoming work adds utility and value. The only thing that needs to be finalized by the end of Sprint Planning is the Sprint Goal, so pay attention. Why are we doing the work that we’re doing this Sprint?
Topic Two: What are we going to do this Sprint? The Product Owner and Developers are going to select work from the Product Backlog that they feel can be done within a Sprint. The Developers are responsible for sizing the work, so they’re going to have a lot of say on how much work is actually brought in. The Developers and the Product Owner may work together to refine those backlog items to make sure that they’re better understood and more likely to be done within that Sprint. Selecting how much work the Developers feel can be done could be a little bit challenging, and so they’re going to look at past performance and who’s in the office this week to make those determinations on how much work they can actually pull in to get done, meeting their Definition of Done.
For each selected Product Backlog item, the Developers are going to work together to create a plan to help those Product Backlog items meet their Definition of Done. This is often done by decomposing the work into smaller, more actionable pieces that can be done in a day or less. The reason you might want this broken down into a day or less of work is so that you have something to talk about in The Daily Scrum as you’re measuring progress towards your Sprint Goal. How this decomposition process is done is at the sole discretion of the Developers. No one in Scrum tells the Developers how to turn Product Backlog items into increments of value.
The Sprint Goal, the Product Backlog items that we have selected for the Sprint, and the plan on how to achieve them, all in combination, are your Sprint Backlog. It’s three parts: why, what, and how.
Sprint planning is time boxed to eight hours or less for a one month Sprint. Usually shorter with shorter Sprint lengths.
A few things to note about Sprint planning: You do not have to have a perfect plan coming out of Sprint Planning; merely enough to get started. Every Daily Scrum, you’re going to adapt your plan anyway, so no sense creating the perfect plan up front. Some people don’t like spending eight hours in a one-month Sprint in Sprint Planning. Remember, it is just a time box. Don’t spend more than eight hours. You can spend less; that’s even better.
If all of this information about Scrum is interesting to you and you’d like to learn more, please join us in one of our Applying Professional Scrum courses, Professional Scrum Master courses, or Professional Product Owner courses. If you have any other questions, feel free to contact us.
