A product backlog is an ordered list of all features, functions, requirements, enhancements and fixes that constitute the changes to be made to a product in future releases. Each item is called a product backlog item (PBI). All items should include a description, value, order and estimate.
Items can also be defined as Epics and Stories. Epics tend to be broken down into multiple stories/ items within the product backlog refinement process.
As product backlogs are ordered, those items higher ranked items should hold more information/ be more defined than the lower level items. The top 20% of the backlog should contain enough detail for the tasks to be worked on immediately. These items should meet a definition of ready and should have been broken down small enough to be achievable within a sprint, no more than 2 weeks worth of work, but as a general rule it is a good guide to have an item which is no more than 5 days worth of work. See What makes a great Product Backlog Item? for additional information on items. This helps to ensure the development team are able to understand the items well, that their estimates are accurate and testing is simpler.
Further down the ordered list, items that won’t be worked on for many months, more or maybe never, should be defined in outline as large pieces of functionality (generally here is where epics come into play). As the items move further up the list, they’re refined and are broken down into smaller items that need to meet the definition of ready when they move into the top 20% of the backlog.
Product Backlogs are ever changing – they’re a living artefact, constantly changing and even the order change change providing the work isn’t being worked on within the current sprint. They evolve as circumstances evolve. Changes to business requirements, market conditions, technology or processes may cause changes in the product backlog.
Good product backlogs are DEEP:
- Detailed appropriately
- Estimated
- Emergent
- Prioritised
