Marathon Planning Events
The team in the example scenario suffered through painful sprint planning sessions. They tried to define requirements for very generic product backlog items that they hadn’t seen before. The time it took to figure out what to build left them no time to consider how to build it.
The rush to figure out the requirements during sprint planning lead to many questions. During the sprint, development team members sought clarification about what they were supposed to implement: They scheduled meetings, sent emails, and dropped by stakeholders’ and subject matter experts’ desks to try to get answers. This led to a lot of frustration in the organization as people outside the team complained about the constant interruptions the team was causing. The team spent most of the sprint frozen as they tried to define exactly what they were supposed to be doing.
While managing the product backlog, the product owner would add product backlog items with little detail. At most, he would include a title and put a few details in the description, but nothing more. The development team paid little attention to what was in the product backlog until sprint planning which caused this painful cycle to continue.
A painful sprint planning event is a sign of an unrefined product backlog. The product owner is accountable for the state of the product backlog, but the development team has some responsibility in it, too. Having a healthy product backlog takes two components:
-
A product owner who manages the product backlog appropriately given the context of the situation. This could mean they are actively involved in adding, updating, removing, and ordering product backlog items. Or it could mean they have delegated some of these responsibilities while still maintaining full accountability for the backlog.
-
A development team usually spends no more than ten percent of their time during a sprint refining the product backlog. These activities include adding details, estimating, decomposing, discussing implementation plans, and performing any other product backlog activities that are necessary to prepare for upcoming sprints. We call product backlog items that have received this kind of TLC from the development team “ready” PBIs.
In the product backlog, items at the bottom and in the lower portion are typically vague, big ideas that are meant to happen in the future. As you work your way toward the top, items become clearer and more implementation-ready. But how much detail should a product backlog item have to be considered “ready?”
A PBI should have just enough detail that the development team can start work on it with a high level of confidence that they can deliver it by the end of the sprint. Too much detail captured too far in advance could have you building the wrong thing. Too little detail and the team might not be able to effectively work on that item during a sprint. If the development team feels like they have enough info to collaborate on a PBI and it can be completed during a sprint, then it’s “ready.”
Painful sprint planning events are common. Often, the Scrum team asks to skip product backlog refinement so they can focus on delivering “real work.” Let this happen. After many years of fighting this battle, we ‘ve found that letting teams experience a bad sprint planning session leads to powerful teaching moments where you can make the value of refinement meetings crystal clear.
To learn more about facilitating effective product backlog refinement sessions, head over to Chapter 5, The Product Backlog.