Mon 9 Jan 2017
A product backlog is a prioritized list of work for the development team that is derived from the road map and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The Product Owner creates, maintains, and regularly re-orders the Product Backlog. The Product Owner uses the Product Backlog to adapt to emerging requirements, customer feedback, and market changes.
What are Product Backlog Items?
The product backlog is composed of product backlog items, or PBIs. Most PBIs are features, items of functionality that will have tangible value to the user and customer. These are often written as user stories (or sometimes use cases or free form tests). Other PBIs include defects needing repair, technical improvements, knowledge-acquisition work, and any other work the product owner deems valuable. The figure below illustrates the product backlog.
The product backlog items can be categorized mainly in four fundamental types:
- Feature: The most common type of PBI is something that is of value to a user or customer - the product features. It can be a brand-new functionality or changes to existing functionality. Features, for most teams, should represent the bulk of items in the backlog.
- Defects: Some teams like to include defects/bugs in their product backlog. High-performance agile teams never let defects live long so they are unlikely to ever have many defects in their product backlogs.
- Technical Work: Some teams like to include defects/bugs in their product backlog. High-performance agile teams never let defects live long so they are unlikely to ever have many defects in their product backlogs.
- Knowledge Acquisition: Another type of PBIs are items that involve knowledge acquisition. During agile development when the team is presented with a high degree of uncertainty a common and effective solution is to research information. Examples include prototype, proof-of-concept, research, experiment, spike, etc.
Creating and maintaining product backlog
The backlog needs regular attention and care - it needs to be managed carefully. At the start of the project the Scrum Team and its Product Owner start by writing down everything they can think of easily. This is almost always more than enough for a first sprint.
After this initial setup, the Product Backlog has to be maintained in an ongoing process that comprises the following steps:
- Ordering the Scrum Product Backlog. The most important items are moved to the top.
- Preparing the high-priority entries for the next Sprint Planning Meeting.
- (Re-)Estimating the entries in the Scrum Product Backlog.
The Product Owner is responsible for making sure that the Product Backlog is in good shape. This is a collaborative process. When using the Scrum Framework about 10% of the Scrum Team’s total time should be reserved for maintaining the Product Backlog (discussion, estimation etc.). The collaborative maintenance of the Product Backlog helps to clarify the requirements and create a buy-in from the Scrum Team.
Characteristics of a good Product Backlog
Good product backlogs share similar characteristics - DEEP: Detailed appropriately, Emergent, Estimated, and Prioritized.
- Detailed Appropriately: The product backlog items will differ in their level of detail. Those that we will work on sooner, those at the top off the product backlog, will be more detailed. Those that we won't work on or some time will be less detailed. We want to refine (add detail to) backlog items as they rise in priority, adding details in a just-enough, just-in-time fashion.
- Emergent: As discussed in earlier chapters, the product backlog is a living document, constantly changing as the product is being developed or maintained. As the team and product owner learn more about the product and the marketplace, they might add new items, discard some, and change others. The emergent nature of the product backlog is not only expected but is a sign of a healthy and functioning product backlog.
- Estimated: Each product backlog should have a size estimate that corresponds to the effort required to develop that item. The product owner uses these estimates to help determine a product backlog item's priority. Ideally most of items at the top of the product backlog will be sprint-sized, small enough to be worked on during a single sprint. Large, high-priority items should be broken into smaller stories prior to being declared sprint-ready (see Definition of Ready for more on this concept).
- Prioritized: A product backlog should be a prioritized list of PBIs, but not every PBI needs to be prioritized. I recommend prioritizing about a release worth of PBIs. Prioritizing beyond that is likely a waste of effort, as too much might change by the time the first release is out. Instead, prioritize new items as they emerge and save the "someday" or "future release" items for later.