Product Backlog Item

You want to establish a Team Focus for a development cycle. This pattern describes how to size backlog items to support _Main Line_ development

Deciding What’s Enough to be Valuable

Getting more things done is appealing, but focusing on one work item enables delivering complete features more quickly. Some features may require multiple backlog items. You want to have complete work to review at the end of a development iteration, but some features seem too large to complete in that time frame.

Incremental Delivery is integral to agile software development. By planning to deliver complete increments of work each development iteration, the team can inspect and adapt the current state of the working software and also the plan. On the other hand there is a tension between planning for incremental delivery and planning for complete features that product owners and stakeholders can give meaningful feedback on.

The vision for a product requirement can sometimes seem hard to break down into units that deliver meaningful value. Features that seem small in concept can be non-trivial to implement and thus can span multiple iterations between initiation and completeness. In other cases, a small thing might not seem valuable enough to include as a feature.

If you plan to complete a User Story {Cohn, 2004 #260909} over multiple iterations, it can be difficult to establish that it’s done. A User Story can be a valuable agenda item for an end-of-iteration review. Requirements can change as users see working software. Partial features are an opportunity for feedback; in some cases, you may discover that a partial implementation could be all you need. In other cases, a partial implementation might lead a stakeholder to discover that the initial vision is flawed. However, splitting features into smaller units can be a challenge.

We want to end a development cycle/Sprint with something complete enough to demonstrate value but perhaps not the end state for a feature.

Size to Fit

** Refine each user story to ensure that each Product Backlog Item for a development cycle is small enough to be completed within the iteration, and so that the iteration backlog is likely to be completed in a sprint.  **

It’s good to limit work on progress and focus on completing items before starting new ones. On an iteration level, each product backlog item can be completed within a single iteration. This is relevant to how you structure your codeines in that each merge to the Main Line should help complete a backlog item. The patterns in A Scrum Book {Sutherland and Coplien, 2019 #38181} and Essential Scrum {Rubin, 2012 #284671} discuss the planning process in more detail.

During planning, Product Backlog Items are refined into items (usually User Stories) that are likely to be completed in that iteration.:

Stories should help build towards end-to-end functionality so that there can be something to demonstrate at the end of the iteration. A good test for a story is to be able to answer these questions:

While a Product Backlog Item can map to a commit or merge, you will want to plan to commit and merge more often if the PBI takes more than a day or so to complete.

There are a few strategies for refining Product Backlog Items to be small, but the underlying theme for all is to develop a “thin” version of the end-to-end system so that you can show working software yet also have something to demonstrate.

A common one is “vertical slices” which starts by implementing a skeleton of the feature, which does something, but with minimal implementations of certain services or components.. A similar concept is Walking Skeleton, a minimal, end-to-end implementation of the system that links together all the main architectural components.

Breaking down a larger feature into smaller parts enables:

Implementing an end-to-end “skeleton” allows you to demonstrate a realistic flow to a user while also identifying areas that might be high risk to implement. Once the skeleton application is available and the basic utility is evaluated, you can add additional functionality and robustness.

Cautions

Be careful to tie Product Backlog Items to business value. Even infrastructure items can have business value. {Berczuk #9707}

Next Steps

Even though small Product backlog items have benefits, in some cases, Product Backlog Items are often too large to use as a basis for a rapid integration pace. A Product Backlog item can sized to be completed in an iteration, but you might want to commit more frequently.