The goal of sprint planning is to ensure the Product Owner (PO), Developers, and Scrum Master are aligned on a plan for the upcoming sprint and collaboratively working toward the sprint goal. According to the Scrum Guide, the sprint planning event addresses the following topics: Topic One: Why is this sprint valuable? The Product Owner […]
The goal of sprint planning is to ensure the Product Owner (PO), Developers, and Scrum Master are aligned on a plan for the upcoming sprint and collaboratively working toward the sprint goal. According to the Scrum Guide, the sprint planning event addresses the following topics:
Topic One: Why is this sprint valuable?
The Product Owner proposes how the product could increase its value and utility in the current sprint. The whole Scrum team then collaborates to define a sprint goal that communicates why the sprint is valuable to stakeholders. The sprint goal must be finalized prior to the end of sprint planning.
Topic Two: What can be done this sprint?
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.
Selecting how much can be completed within a sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their definition of done, the more confident they will be in their sprint forecasts.
Topic Three: How will the chosen work get done?
For each selected product backlog item, the Developers plan the work necessary to create an Increment that meets the definition of done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn product backlog items into increments of value.
The first topic results in the sprint goal. The second identifies the highest priority product backlog items (PBIs, often referred to as user stories or stories) from the product backlog. This will become the scope for the sprint. The third topic breaks down the PBIs into smaller, executable tasks.
For example, the way sprint planning worked on my last team was by the Scrum team first getting together. The Product Owner begins the session by briefing the team on key business or product goals they want to accomplish. From there, the Product Owner presents the highest priority PBIs to the team. The team asks clarifying questions and the PO helps answer questions and provide insights. The Developers then determine how many of the highest priority items they can achieve in this sprint. Finally, the Developers will break the PBIs into smaller tasks. The session is concluded with aligning around a sprint goal and answering any closing question or thoughts.
The Product Owner, Scrum Master, and Developers all belong in sprint planning.
I recommend that all the Developers attend sprint planning. Why? We want all the developers to hear the same message, to be able to express their thoughts and ask questions, and provide any input.
I was once on a team and chatting with one of the Developers. The Developer said, “You know what I like about working here as Developer? I like that they don’t treat us like mushrooms. I felt like my old company treated developers like mushrooms.”
I asked, “What do you mean by mushrooms?”
Developer, “You know, like a mushroom. They keep you in the dark and feed you manure, like a mushroom.” I thought that was a great point; we want our developers to be fully involved, so we want them in sprint planning.
I generally do not recommend inviting non-Scrum team members to sprint planning. Non-Scrum team members should be met with prior to sprint planning to understand their needs and priorities. Having non-Scrum team members in sprint planning can be distracting.
With that said, there are exceptions for when we may want non-Scrum team members to join. For example, we might be doing a lot of work in a certain stakeholder’s area in this sprint. In that case, we could approach that stakeholder and say, “for this sprint, we’re going to be do a lot of work in your area. Can you sit in sprint planning with us? That way you can help answer questions and provide more insights. We’ll even talk about your items first so as soon as we’re done with your items, you can head out.”
My recommendation is if you want to invite others that make the sprint planning meeting more effective, that’s great. But I prefer to leave non-Scrum team members that make the meeting slower or less effective out.
The Scrum Guide says “Sprint planning is timeboxed to a maximum of eight hours for a one-month sprint. For shorter sprints, the event is usually shorter.” This means we recommend no more than 2 hours per week of sprint duration. For a 2-week sprint, this means no more than 4-hour timebox for the planning meeting.
The input to sprint planning is an effectively refined product backlog. This refined product backlog has an ordered list of PBIs that the team will be exploring during sprint planning. The product backlog is owned by the Product Owner.
The output to sprint planning is the sprint backlog. The sprint backlog contains all the PBI’s the team is going to implement during the sprint, broken down into smaller tasks, and focused around a sprint goal. The sprint backlog is owned by the Developers and often visualized as shown below:
During spring planning, the Product Owner talks about the sprint goal, presenting the highest priority PBIs, and answers the team’s questions.
Note that the Product Owner is neither writing PBIs, nor creating acceptance criteria, nor prioritizing the product backlog. That happens during product backlog refinement. Click here to learn more about refinement and definition of ready.
Scrum is a framework that operates in a rhythmic cadence called “sprints,” which are fixed...
The Scrum framework includes a pattern of five activities that allow a small team to...