Most sprint planning meetings I have attended were fun. The ones that weren’t involved a poorly groomed product backlog, whose high-priority items were not workable, not ready to be pulled into the sprint. When the backlog hasn’t been prepared prior to the meeting, the product owner and team often carry out impromptu grooming activities. These consume valuable planning time and usually result in poor requirements and weak commitments. Plus, everyone is fed up and exhausted by the end of the meeting. As a consequence, the product backlog items that are likely to be worked on in the next sprint have to be prepared prior to each sprint planning meeting. Although it is the product owner’s job to make sure that the work gets done, preparing the product backlog should be teamwork involving the product owner, ScrumMaster and team. We begin the preparation work by choosing a sprint goal.
Choosing a Sprint Goal
The sprint goal summarizes the desired outcome of the sprint. It should move the Scrum team a step closer toward its goal – delivering a successful product. One product owner I worked with selected the following goal for the first sprint of a new-product development project: “Tall trees have deep roots.” The goal nicely summarized the purpose of the sprint: laying the foundation for the remainder of the project. A good sprint goal is broad but realistic. It should leave some room for the team to maneuver and still be valid if the team does not commit to all the top product backlog items. As with all grooming activities, the team should participate in formulating the goal. This ensures clarity and buy-in.
Sprint goals are beneficial for several reasons:
- They create alignment among the product owner, ScrumMaster, and team: Everyone is working toward a common goal.
- They minimize variation by limiting the type of requirements worked on in a given sprint, for instance, by choosing items from the same theme. This facilitates close teamwork and can help increase velocity.
- They make it easier to communicate to stakeholders what the team is working on.
Once the goal has been set, all relevant items should be found at the top of the product backlog. Note that the goal is also discussed at the beginning of the sprint planning meeting to ensure that everyone is aware of the sprint’s desired outcome. But if you wait until the meeting to think about the goal, your product backlog prioritization may well be wrong, and the wrong items may have been prepared.
Preparing Just-Enough Items Just in Time
Once a sprint goal is chosen, we prepare just enough items for the upcoming sprint, just in time. The grooming activities in the first sprint focus on the items for the second sprint, and those in the second sprint on the items for the third, and so on. (Large projects require looking ahead two to three sprints.) Preparing just-enough items just in time provides a number of benefits: It minimizes the amount of time and money spent on describing product backlog items, and it keeps the inventory of detailed items low—providing more information than required is wasteful. By detailing only the items that are likely to be chosen for the upcoming sprint, we let the product backlog evolve based on customer and user feedback.
How many items should be prepared depends on the team’s velocity and the desired granularity of the items. The higher the team’s velocity, the more items have to be prepared. It is helpful to groom a few extra items to give the team some flexibility. They also come in handy if the team’s sprint progress is faster than anticipated. I find it beneficial to work with small requirements that can be “done” within a few days, independent of the sprint length. This improves the team’s progress tracking within the sprint and therefore its self-organization: A team’s progress is based not only on its remaining tasks but also on how much newly implemented functionality has been tested and documented. Small requirements also minimize the amount of work in process and the risk of partially done and defective work at the end of the sprint. In addition, small items facilitate realistic commitments. Large ones can contain so many tasks that the team might fail to identify them all.
Decomposing Items
To ensure that the high-priority product backlog items can be turned into a product increment, we decompose them by making them smaller and smaller until they fit into the next sprint. This process, also known as progressive requirements decomposition, might last more than one sprint. You might have to start decomposing a product backlog item a few sprints in advance before it can be implemented, particularly if the item is large and complex. This allows gathering the necessary feedback from customers, users, and other stakeholders before detailing the item. Let’s look at how user stories can be decomposed progressively.
Figure 1
Decomposing user stories
As illustrated in Figure 1, the Scrum team originally placed the epic “Compose email” in the product backlog. As it is too big and vague to be delivered in a sprint, the epic is broken down into several coarse-grained user stories. The story “State recipient” is then further decomposed into two fine-grained user stories. These are now small enough to fit in a sprint. The epic is an example of a compound story, a user story that has more than one goal. To decompose such a story, we introduce a separate story for each goal. “Compose email” is therefore broken into “State subject,” “State recipient,” and “Set importance.”
Ensuring Clarity, Testability, and Feasibility
Once an item is small enough, we must ensure that it is clear, testable, and feasible. (For user stories, you may alternatively apply the INVEST criteria; these suggest that each story should be independent, negotiable, valuable, estimatable, small, and testable.) A requirement is clear if all Scrum team members have a common understanding of its semantics. Collaboratively describing requirements and expressing backlog items in a simple and concise form facilitate clarity. An item is testable if there is an effective way to determine whether the requirement is satisfied within the sprint in which it is implemented. Stories must have acceptance criteria now to ensure that each story is testable. An item is feasible if it can be completed in one sprint, according to the team’s definition of done. To ensure feasibility we consider dependencies on other items, including functional and nonfunctional requirements. If a story is constrained by a user interface requirement, for instance, it must be clear what the resulting product increment should look like. If that is not the case, the team should explore the user interface requirement before the story is delivered as part of the product increment. If exploring the item requires a large effort or carries a high risk, the exploration should be tackled in a separate sprint, for instance, by implementing a throwaway prototype to investigate the user interface design.
Summary
Carefully preparing the product backlog for the upcoming sprint planning meeting is key to creating successful product. It ensures that the sprint planning meeting is effective resulting in a strong and realistic commitment. If your product backlog is not as well prepared as it should be, then start with establishing a product backlog grooming process. This allows product owner, ScrumMaster and team as well as stakeholders such as customers, users, marketing, sales and management to jointly work on the product backlog on a regular basis.
