Product backlog
backlog / it is in the backlog / sprint backlog / refinement
A product backlog is the ordered list of everything a team might build next. The Scrum Guide calls it the single source of work for the team. Agile Alliance is explicit that including an item does not guarantee it will be delivered, so being in the backlog is not a commitment.
The Scrum Guide packs the useful part into one sentence: the product backlog is an emergent, ordered list of what is needed to improve the product, and it is the single source of work undertaken by the team. Two of those words do real work. Emergent means the list changes as understanding changes. Ordered means position carries meaning, which makes where an item sits the only interesting fact about it.
Agile Alliance then says the thing that answers the question most people are actually asking. In contrast to a requirements document, the inclusion of an item in a product backlog does not guarantee that it will be delivered. Being in the backlog is a statement about consideration, not about schedule.
It also warns against the comparison people reach for. A backlog should not be confused with a requirements document. A requirements document is baselined and expected not to change after a point. A backlog evolves as understanding of the product evolves. And backlog items are necessary but not sufficient to describe the intended change, because the complete understanding comes from the conversations held about each item.
Two roles are worth knowing, because they decide different things. The Scrum Guide says the developers who will do the work are responsible for sizing it, and that the product owner may influence them by helping them understand and select trade-offs. Items that can be finished within a single sprint are the ones deemed ready to be selected.
In practice
When a request goes into the backlog, two questions turn a vague answer into a real one. Where is it in the order, and has it been refined enough to be selectable yet. An item sitting unrefined at position ninety is not scheduled, however sincerely it was added. An item near the top that has been broken down and sized is about to happen.
Not the same as
- A requirements document
- That is baselined and expected to stay still. Agile Alliance says the backlog evolves as understanding does.
- A roadmap or a commitment
- Inclusion does not guarantee delivery, in Agile Alliance's own words.
Why it matters to you
Most disagreements about software delivery come from one phrase doing two jobs. The team says it is in the backlog, meaning it has been recorded and considered. The person paying hears it as scheduled. Both leave the conversation satisfied and one of them is wrong. Knowing the list is ordered, and that position rather than presence is the information, makes that conversation short.
What to ask or check
- 01Where is this item in the order, and what sits above it?
- 02Has it been refined and sized, which is what makes it selectable?
- 03Who decides the order, and when was it last reordered?
What people get wrong
That being in the backlog means the work is scheduled. Agile Alliance states that inclusion of an item does not guarantee it will be delivered.
Red flags
- A request answered with it is in the backlog, and no position given.
- A backlog presented as a requirements document, when it is expected to change.
- Items promised from the backlog that have never been refined or sized.
Who owns it
The Scrum Guide gives sizing to the developers doing the work and lets the product owner influence trade-offs. Ordering is a decision somebody made, which means it can be asked about.
Where you will see it
In every conversation with a development team about something you asked for and have not received.