Product Backlog


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!


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.


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.

  1. 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.
  2. Capture the requirements individually with a clear description for each that covers; Why (usually Stories) and What (Acceptance Criteria and Definition of Done).
  3. 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.
  4. 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.
  5. 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.

Stay in touch and sign up to our newsletter!

Scrum Master

Discover the essential responsibilities of a Scrum Master. Facilitating success and fostering collaboration as a servant-leader.

Product Owner

What makes a great Product Owner? Like a gourmet chef, here are the essential ingredients to maximising product value.

Sprint Review

This recipe will guide you to prepare and cook a good Sprint Review. It´s all about sharing results and conclusions, receiving feedback and getting well aligned with your stakeholders. Prepare service, serve it fresh and get happy customers!

About The Scrum of Things Cookbook

Our cookbook is a guide on Scrum like no other. We want others to be able to easily learn about and try out Agile ways of working and so created the idea of a cookbook; a fun way to be guided through the essentials.

Sprint Retrospective

The Sprint Retrospective is for the Scrum Team to look back on how working in the sprint went and decide together if and how to improve.

Sprint Planning

Just like cooking a delicious meal, Sprint Planning requires preparation, collaboration, and attention to detail. In this recipe you learn how to effectively plan a sprint.

Product Backlog

The Product Backlog encompasses the value you want to deliver. It should entice your stakeholders' taste buds and inspire the team to serve up the value!

Daily Scrum

Like a good breakfast, the Daily is a vital part of every working day. Read our recipe to making your Daily truly scrumptious!