In my experience, Sprint Planning is the most misused event in Scrum. There is a lot of competition for this dubious title. Many teams skip the Sprint Retrospective, which is critical for continuous improvement. Many other teams don’t hold a Daily Scrum, hampering their ability to deliver a Done increment. Some teams even skip Sprint Reviews, making inspecting the increment and adapting the Product Backlog a hit-and-miss activity.
So, why am I calling out the Sprint Planning event in particular?
When I say that the Sprint Planning event is misused, I don’t mean that Scrum teams skip the event altogether. Teams rarely skip Sprint Planning. What I mean is that Spring Planning is one of those events that even experienced teams don’t use to its fullest potential.
Here’s why. Many teams see the Sprint Planning event as the time for selecting which Product Backlog items (PBIs) they will deliver in the upcoming Sprint. And that’s it. There is so much more that teams can do to maximize the value they get from Sprint Planning.
While the 2020 Scrum Guide does not provide agendas or outlines for any of the events in Scrum, it does refer to three topics for the Sprint Planning event to cover. These topics are as follows:
Why is the Sprint valuable? (Sprint Goal)
What can be Done this Sprint? (Selected PBIs)
How will the chosen work get done? (Plan for delivery)
Even with the 2020 Scrum Guide deliberately spelling out these topics, many teams only discuss the second topic.
Why set a Sprint goal?
The first topic that the Scrum Guide suggests for the Sprint Planning event is to identify why the coming Sprint is valuable. This “why” for the Sprint refers to the Sprint Goal. The Sprint Goal describes the overall value the upcoming Sprint will provide to the organization.
Many Scrum Teams I’ve talked to do not set a goal for every Sprint. They’re missing out on the focus this exercise provides to the team.
Imagine that a Scrum Team has selected ten PBIs. About halfway through the Sprint, the team realizes that they are not on track to deliver all ten items. They will need to reduce the Sprint’s scope. But which PBIs should they remove, and which should they prioritize? It’s difficult to decide without a clear Sprint Goal.
The Sprint Goal also recognizes that, in a complex environment, we can’t know (predict) what will happen during the Sprint. That’s why the Scrum Team commits to delivering a Done increment that meets the Sprint Goal, not the particular PBIs they selected during Sprint Planning.
It’s a subtle but critical difference.
If things don’t go as well as planned during the Sprint, the Developers will engage the Product Owner to discuss which PBIs to remove from the Sprint to give the team the highest chance of delivering a Done increment that meets the Sprint Goal.
The benefit of a plan for delivery
During Sprint Planning, the Scrum Team should discuss their plan for delivering the PBIs they selected for the Sprint. They don’t have to detail every single day’s activities step by step, but they should think out enough of a plan to get started, with the rest of the plan left to emerge during the Sprint. Planning can also identify any dependencies among Scrum Team members and how to handle them, which avoids the waste that comes with bottlenecks. For example, in a Sprint focusing on painting a living room, we need to discuss who will select the color and who will buy the paint so that we have just one person investigating color options and one person buying paint, thus avoiding duplicative work.
As each team member talks through their approach to completing the tasks, the team gets valuable feedback to inform the work and gain efficiencies.
The Sprint Planning event is about more than selecting which PBIs the team will deliver in the upcoming Sprint. It’s essential that the Scrum Team also use Sprint Planning to craft a Sprint Goal that describes why the Sprint is valuable. Their discussions should also include a high-level plan for delivering the selected PBIs. Including these aspects increases the team’s focus and gains efficiencies. Combining all three of these planning areas increases the likelihood of delivering a Done increment that meets the Sprint goal every Sprint.