The Product Backlog in Scrum
The product backlog is a prioritized, ordered list, typically sorted by business value and risk. it contains product backlog items that describe the work needed to accomplish the project. Product backlog items are often expressed as user stories but may also contain functional requirements, nonfunctional requirements, bugs and various issues. The product backlog is often estimated in abstract units such as story points, which use a relative weighting model. The product backlog is owned and managed by the product owner. The definition of done heavily influences it as well.
Product Backlogs & Release Planning
The release plan can be derived through calculations on the product backlog. Each sprint, the developers will have a number of stories it can output. This number becomes the team’s velocity. Velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.
Once established, velocity can be used to plan projects and forecast release and product completion dates. The product owner can estimate what stories will be complete, and when, by viewing the size of the story and fitting stories into sprints based on the velocity the team is able to execute.
Managing the Product Backlog
The Product Backlog should follow Bill Wake’s INVEST model (external link)where stories should be:
- I - Independent
- N - Negotiable
- V - Valuable
- E - Estimable
- S - Small
- T - Testable
Sample Product Backlog:
