Product Backlog

A product backlog is an ordered list of work a team might do on a product: features, fixes, improvements and investigations. It's a central artifact in Scrum and most other agile methods. The ordering is the point. A backlog isn't a set of tasks to be completed but a ranking that says what's most valuable to do next, and the team pulls work from the top.

Items near the top are expected to be detailed: small, clear enough to estimate, with agreed criteria for when they're done; see User Story and Definition of Done. Items lower down can stay vague, because they may change or vanish before anyone works on them. That gradient is deliberate. Detailing work far in advance wastes effort on plans that won't survive contact with what the team learns.

Backlog refinement, once commonly called grooming, is the ongoing work of keeping the list useful. Teams split large items into smaller ones, clarify requirements, estimate, reorder as priorities shift, and delete what no longer matters. Scrum suggests spending a modest share of each iteration on it rather than holding one long planning session.

Ordering is the hard part. Methods help structure the conversation. MoSCoW sorts items into must have, should have, could have and won't have this time. Others weigh value against effort, or rank by the cost of delaying each item. None removes the judgment, and the person ordering the backlog, in Scrum called the product owner, holds real power over what gets built.

The common failure is a backlog that only grows. Every idea, request and bug report gets added; few are removed. After a year it may hold hundreds of items, most of which will never be built, and nobody reads past the first page. A long backlog is costly: it has to be searched, re-estimated and re-sorted, and it implies promises to the people whose requests sit in it. Some teams cap its length or delete items older than a few months, reasoning that anything important will be requested again. Shape Up drops the shared backlog entirely in favor of fresh proposals each cycle.

Backlogs usually live in an issue tracker, often alongside a separate stream of incoming bug reports that must be sorted before they join it. Flow-based teams visualize the same list as a board's leftmost column. A backlog can also become a tool for avoiding scope decisions, accepting every request so nobody has to hear no; see Feature Creep and Minimum Viable Product.