Product Backlog
Description
The Product Backlog is the menu of carefully curated dishes. Each dish is clearly described but, importantly, how the dish is made is up to the team of cooks and is dependent on their skills and cooking flair!
Ingredients
1 list of Product requirements (see preparation)
1 tool or location for storing the Product requirements*
* The Product Backlog needs to be in a simple tool/location that can be actively managed, updated, and accessible to anyone who is interested e.g Post-its, Excel, digital whiteboard, Jira, Azure dev-ops.
Preparation
When starting a new team, it takes time to create the initial Product Backlog. This can be done in advance or during a Sprint Zero.
Customer requirements, Stakeholder requirements, Risks, Enablers, and the High Level Plan (if using) need to be gathered as input to the Product Requirements – and revisited regularly throughout delivery.
Cooking method
The Product Owner is responsible for creating the Product Backlog, however the end result is the Product, for which the whole team is accountable. The team should therefore be actively engaged in supporting the Product Owner with the creation and maintenance of the Product Backlog.
- Discuss with stakeholders what the requirements are for the business and users to gain value from the Product. It is the Product Owner’s responsibility to understand and gather these requirements.
- Capture the requirements individually with a clear description for each that covers; Why (usually Stories) and What (Acceptance Criteria and Definition of Done).
- Use input from stakeholders and the team to prioritise the list of requirements. Prioritisation can be based on different criteria e.g. Value, Time criticality, Risk, weighted shortest job first, all or a mixture of these things.
- Refine each item with the team to understand the size of them; ideally one Product Backlog Item is ‘doable’ in a Sprint. Note that the team will use the Product Backlog as the basis for their Sprint Planning and Sprint Backlog by breaking each item down into smaller tasks (the how); the Why and What (how do we know when it is done) therefore need to be very clear.
- Repeat the method! The Product Owner must continuously work to keep the backlog up to date, refining it and aligning it with stakeholders and the team.
Your Product Backlog should now contain a list of items that are: prioritised, understandable, in one list, and each item ‘doable’ in a Sprint.
Product Owner responsibilities:
- Explain why
- Assess business value
- Align with stakeholders
Scrum Master responsibilities:
- Support P.O.
- Coach stakeholders
Developer responsibilities:
- Make estimates (sizing)
- Suggest Definition of Done
Cooking tips
- Focus on the Why. One common mistake is to focus on how to do things and estimating them. The Product Backlog is not a work breakdown structure, but a tool to create alignment and understanding across the whole organisation. To leave the How to the Developers builds motivation and empowerment.
- It’s tricky to find the right level for the Acceptance Criteria. They should be crisp enough so that the Scrum team understands what needs to be done, but not so detailed that they define the solution itself.
- Refining the Why (e.g a User story, but not an Acceptance Criteria) and the prioritisation is often beneficial to do before the Sprint Planning. The Product owner and relevant stakeholders align on key items to work on in the near future.
- If, during Sprint Planning, a Product Backlog Item is found to be too large to complete and deliver its value in a Sprint, then the team and Product Owner can negotiate on the Acceptance Criteria to something more manageable and a future iteration of that Product Backlog Item can be added to the Product Backlog as a new item for clarity.
