“It is the single source of requirements for any changes to be made to the product.” (1)
Overview
Definition: The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for the product (2, pg 46)
Owner: Product Owner is responsible
Product Backlog Characteristics
- Exists as long as the Product exists
- One single list for everything
- One Product = One Product Backlog = One Product Owner (2, pg 46)
- Grows as marketplace feedback is received, product gains value, technology changes etc
Product Backlog Contents
- Product Backlog Items of all changes to be made to the Product including
- Features
- Functions
- Requirements
- Enhancements
- Fixes
Product Backlog Items
- Description, Order, Estimate, and Value
- Product Backlog items often include test descriptions that will prove its completeness when “Done”
Product Backlog Refinement
Definition: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.
Length: “Refinement usually consumes no more than 10% of the capacity of the Development Team” (1)
People: Product Owner, Development Team
Outcome: Product Backlog items become more transparent through refinement and the top items are deemed ‘Ready’ for a Sprint (i.e. can be ‘Done’ by the team within one Sprint)
Product Backlog Details
- Greater clarity and detail on the items higher up the order
Product Backlog Estimates
- ‘More precise’ estimates (1) are made with greater clarity (i.e. higher up the backlog order)
- Development Team is responsible for all estimates
- Product Owner may support in collaboration
Product Backlog Order
- Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones
Monitoring Progress Toward Goals
- Product Owner is responsible for monitoring progress and making this transparent to Stakeholders
- Remaining total work to reach a goal can be summed at any point
- The Product Owner tracks work remaining at least every Sprint Review and compares to previous Sprint Reviews to assess progress toward completing work by the desired time for the goal.
Monitoring Practices
NOTE: No practice replaces the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.
- burn-downs
- burn-ups
- cumulative flows
Extra: Product Journey
- What is the business direction?
- Focus on who your target customer is (my notes coming soon)
- Workshop plan to create personas
- Focus on what the problem is
- Use product metrics to analyse and define a baseline
- Prioritise which problem to fix
- Form a hypothesis
- Test your hypothesis
- Tips on User Interviews
- Communicate your Product Vision
- Create the Product Backlog
- Break down stories with User Story Mapping
- Tips on User Stories
- Estimate the Product Backlog Items
- Prioritising the Product Backlog
- Build your MVP
- Monitoring progress towards a goal through roadmaps
- Refine the Product Backlog
References
- The Scrum Guide
- Scrum Insights for Practitioners by Hiren Doshi
Explore Other Scrum Artifacts
 |  |
