Managing a Backlog
The backlog answers the question the timeline and the board both dodge: of everything we could do, what comes next — and why that? It is the only project view whose entire job is deciding what not to work on yet.
In short
- A backlog is ordered, not grouped. Exactly one item is next. “These five are all high priority” is not an order.
- Detail belongs at the top, not everywhere. Items get smaller and clearer as they rise; specifying the bottom of the list is wasted work.
- Refinement is a habit, not an event. A backlog only stays usable if something drains it and something shapes it, every week.
- An item nobody will ever pull should be deleted. A backlog that only grows has stopped being a decision-making tool.
What a backlog actually is
A backlog is a single ordered list of everything the team could work on, most important first. That is the whole definition, and the word doing the work is ordered.
Most teams get this wrong in the same way: they sort items into priority buckets — High, Medium, Low — and end up with thirty items marked High. Buckets feel like prioritisation because they involve making judgements, but they answer the wrong question. The team does not need to know that eight things matter. It needs to know which one to start on Monday morning.
Forcing a strict sequence is uncomfortable precisely because it is where the real decision lives. If two items genuinely cannot be separated, the tie-break is cheap — pick either. What is expensive is never making the call, because then it gets made informally, by whoever is loudest or whichever ticket happens to be open.
Detail belongs at the top
The second property of a healthy backlog is that it is not uniformly detailed. Items near the top are small, well understood and estimated. Items near the bottom are large, vague and unestimated — deliberately.
This gradient is what makes a backlog cheap to maintain. Writing acceptance criteria for item forty is not diligence; it is speculative work on something that may never be built. Specify late, and specify only what is about to be pulled.
Refinement: the habit that keeps it usable
Refinement is the recurring work of moving items up the gradient: splitting large items, adding the detail that makes them startable, estimating them, and deleting the ones that no longer matter. Most teams do this in a short session once a week or once a sprint.
A useful test for whether an item has crossed the line — sometimes formalised as a Definition of Ready:
- Anyone on the team could start it tomorrow without a meeting to find out what it means.
- It is small enough to finish inside one cycle. If it cannot, it is still an epic and needs splitting.
- You can say how you would know it worked. Not a full spec — a checkable outcome.
- Its dependencies are known, and any that are external are already in motion.
How to decide the order
Ordering is a judgement, but it should be an argued judgement. Three lenses that make the argument concrete:
| Lens | The question it asks | Best for |
|---|---|---|
| Value vs. effort | What is the most outcome per unit of work? | A first sort, quickly — it surfaces the cheap wins and the expensive nice-to-haves |
| Cost of delay | What does it cost us for every week this is not done? | Separating genuinely urgent work from work that merely feels urgent |
| MoSCoW | Must, Should, Could, or Won't have this time? | Fixed-date releases, where the valuable column is “Won't” |
Whichever you use, two things matter more than the method. First, the ordering must be visible — if only one person knows why item three sits above item four, the backlog is not a shared artefact. Second, it must be allowed to change. Reordering in response to new information is the system working; a backlog frozen since kickoff has quietly become a plan.
Keeping a backlog healthy
The graveyard
Hundreds of items nobody will ever pull. Every one costs attention at each review. If an item has sat untouched for a year, deleting it loses nothing — if it matters, it will come back.
Only one kind of work
A backlog of nothing but features means maintenance, bugs and technical work are being decided somewhere invisible — usually by whoever is on call that week.
The parallel queue
If urgent work arrives by direct message and skips the list entirely, the backlog stops describing reality and the team's real priorities become undiscussable.
One number is worth watching: the age of the oldest item above the ready line. If something has been ready for months and never pulled, it was never actually that important — and the order is lying to you.
Who lives in this view
The backlog is the home screen for whoever owns what gets built.
| Role | What the backlog tells them |
|---|---|
| Product owner / requester (home view) | Whether their intent is actually reflected in what happens next — and what they are implicitly saying no to |
| Project manager (home view) | Whether there is enough ready work to keep the team moving, and where scope can be cut if the date is at risk |
| Team members | What is coming, so today's decisions do not paint tomorrow into a corner. They pull from the top; they do not need to read the tail |
| Sponsor / stakeholder | The trade-offs being made on their behalf. This is the view to bring to a steering meeting — not the board |
The failure worth naming: when stakeholders are shown the board instead of the backlog, they see activity and assume alignment. The backlog is where disagreement about priorities actually surfaces, which is exactly why it is the uncomfortable one to share — and the useful one.
How this looks in AB
In AB Project Management the Backlog is one view onto the same tasks that appear on the Kanban board and the Gantt view. Ordering is explicit rather than implied by due date, so a re-order is a real decision recorded against real records. Because subtasks live under their parents, a large item can be split in place as it rises — the epic becomes a parent with children rather than being retyped as new tickets — and its progress rolls up automatically once work starts. Items pulled into the board keep their history, so nothing is lost in the hand-off between deciding and doing.
Terms used on this page
Every term below is defined at more length in the full project management glossary.
- Backlog
- A single ordered list of everything the team could work on, most important first. A prioritisation device, not a storage cupboard. More →
- Refinement
- The recurring work of splitting, clarifying, estimating and deleting backlog items so that what reaches the top is ready to start. Sometimes called grooming.
- Definition of Ready
- The test an item must pass before the team will start it — understood, small enough, checkable, dependencies known. The entry gate, where Definition of Done is the exit gate.
- Definition of Done
- The team-wide checklist every item must satisfy before it counts as finished. More →
- Epic
- An item too large to finish in one cycle. Perfectly fine at the bottom of a backlog; a problem the moment it reaches the top unsplit.
- Story point
- A relative unit of size combining effort, complexity and uncertainty. Deliberately not hours — the point is comparison, not conversion. More →
- MoSCoW
- Sorting requirements into Must, Should, Could and Won't have. The “Won't” column is the one that does the work. More →
- Cost of delay
- What it costs, per week, for a piece of work not to exist yet. Turns “this feels urgent” into a number two people can argue about.
- Velocity
- How much the team completes per cycle. Used with the backlog to forecast how far down the list you will realistically get. More →
- Scope creep
- Gradual expansion through small additions. A visible, ordered backlog is the cheapest defence: every addition has to displace something. More →
Related reading
Where the items go next
Pulled off the top of the backlog, work enters the flow — and the limits that govern it.
5.2 Kanban Boards →Where the items come from
Scope definition decides what is even eligible to enter the list.
3.1 Defining Scope →When priorities change
Reordering is healthy; unrecorded change is not. Where the line sits.
6.2 Issue & Change Management →