What Is a Product Backlog?

It's a single ordered list of everything needed to improve the product — not a to-do list and not a wish list. The Product Owner decides the order, the items nearest the top are the most detailed, and a backlog that only ever grows is a warning sign.

Most teams have something they call a backlog. Rather fewer have what the Scrum Guide describes. The difference usually isn't the tool — it's that a real product backlog is a single ordered list with a purpose behind the order, while what many teams keep is an ever-growing pile of requests nobody has the authority to refuse.

Ordered, not prioritized into buckets

This is the distinction that most often separates a working backlog from a broken one. A product backlog is a single ordered list: there is a first item, a second item, a third. It is not a set of piles labelled High, Medium and Low.

The reason is practical. Three items marked "High" still don't tell the team which to build first — so somebody decides informally, usually whoever asked most recently or most loudly. Forcing a single order forces the trade-off to be made deliberately, by the person accountable for it.

Who decides the order

The Product Owner does, and it's their central accountability. They may order by value, urgency, return on investment, dependency, risk, or any combination — and they can take advice from anyone, including the Developers during refinement. But the decision is theirs, which is what makes the role hard: see what a Product Owner actually does.

Not every item needs the same detail

Refinement is the ongoing work of breaking items down and adding detail — a description, an order, a size. What surprises people is that refinement is deliberately uneven: items near the top are small and well understood, while items near the bottom can be a vague one-line idea.

Sizing — commonly in story points — is done by the people who'll do the work, the Developers, with the Product Owner influencing but not dictating it. Items small enough to be finished within one Sprint are the ones considered ready for selection at Sprint Planning: see what a Sprint is.

The Product Goal lives in it

The Product Backlog isn't only a list of work — it also contains the Product Goal, the long-term objective the team is working toward. The rest of the backlog exists to define what will fulfil that goal, and the team commits to one goal at a time: it must be achieved or deliberately abandoned before the next is taken on.

That's what stops a backlog becoming a directionless queue. If you can't say which goal an item serves, it's worth asking why it's on the list at all.

The warning sign: a backlog that only grows

Backlogs are supposed to shrink as well as grow. If items are only ever added and nothing is ever removed, that usually means nobody is saying no — every stakeholder request gets filed rather than declined, and the list becomes an archive of things that will never be built.

Does Kanban have one?

Not in the Scrum sense. The Product Backlog is a Scrum artifact with a defined owner and rules; flow-based methods keep a queue of work but don't prescribe the same structure or accountabilities. We compare the two approaches in Kanban vs Scrum. And if managing one sounds like the job you want, the route in is in how to become a Product Owner.