Chapter 10
Sprint Planning

Development Team Member:

Does Scrum ever end? I feel like we’re running on a hamster wheel heading nowhere.

Todd was working with a team at an insurance company when he witnessed the following scenario:

The Scrum team was an hour into the sprint planning event and there was a collective feeling that it had just begun. They spent this first hour exploring the meaning of a single product backlog item. They clarified the user-story format, added acceptance criteria, and drew a mockup of the user interface on a whiteboard. After the development team estimated the item, the product owner became unsure whether the value was worth the effort and started debating whether the item should be built at all. The team was stuck.

This pattern continued with the next product backlog item. The Scrum master became restless and called for a break as the meeting reached the two-hour mark. The development team had yet to bring a single item into the sprint. The Scrum master thought to himself, “How in the world are we ever going to build this complex portal if we can’t even create a plan for a sprint?!”

When the event resumed, the product owner was gone–he had to run to a meeting with stakeholders. The parting advice he gave was to “fill the sprint backlog and I’ll check to see if I like what it looks like this afternoon”. So that’s exactly what the development team did. They quickly created a bunch of slapdash PBIs so they could end the meeting and get to work.

As development work began, there was no cohesion within the Scrum team as to the expected outcome. Issues surrounding the scope of sprint backlog items became the focus of most daily scrums. Fifty percent of the sprint was spent trying to define the scope of the work for the sprint. The whole team was frustrated.

Did that scenario sound familiar? If so, you’re not alone. We often run across situations like this: planning meetings that drag on forever, product owners who aren’t always available when the development team needs them during this event, and PBIs that aren’t detailed enough to get the work started. This leads to chaotic sprints, low-quality increments, and strained teams.

The sprint planning event is the first event in a sprint, and the entire Scrum team attends. The output is a sprint backlog (containing a forecast and a plan) and sprint goal that the team can self-organize around.

There are two sides to the discussions that occur in sprint planning:

1. What are we building - The product owner comes prepared with an ordered product backlog. A PBI should have enough detail that the development team can consider it as a candidate to bring into the sprint backlog. The level of detail depends on the context of your situation. In some circumstances, a vague idea may be good enough. Others will require that PBIs be refined heavily leading up to the sprint.

2. How are we going to build it - As the development forms the sprint backlog, they collaboratively discuss approaches to the problem at hand. More work will emerge during the sprint—i’s important to be cognizant of that. We want the development team to feel confident in what they are setting out to accomplish, believing it’s possible and taking ownership of it. The plan they develop should be enough to lift them off the ground as the sprint starts. A fully detailed implementation that implies certainty is not the goal. The sprint backlog, consisting of a plan and forecast, are owned entirely by the development team.

Both parts of the discussion, the what and the how, happen recursively as each PBI is inspected and the sprint backlog begins to form. This is not a typical planning meeting as it requires an immense amount of collaboration from the entire Scrum team. We, as Scrum masters, are there to facilitate and bring that collaboration to life.

In this chapter, we’re going to explore the sprint planning event and see where it can go wrong by examining the scenario we just described. This story illustrates several anti-patterns that you should try to avoid and which can lead to extremely painful sprint planning events. If these anti-patterns are already present in your organization, we’ll suggest strategies for fixing them.