Getting the Product Backlog Ready for Sprint Planning

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

Pages

About the author

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.