Backlog Management
Backlog management is the upkeep of a single list of remaining work, ordered by priority, from which a team draws as its capacity frees up. It turns on six decisions: what goes onto the list, how an item is described there, how it is tracked, how it is reviewed and prioritised against all the others, how it is selected to be worked and how it leaves. What makes it workable at any size is that the detail concentrates at the top: the items at the top are described and estimated closely, those at the bottom get the minimum of work needed to understand what they are about. The deliverable is the backlog itself, ordered and dated by its last review.
Goal
The backlog is used to record, track and prioritise the work that remains. It answers a permanent situation: the volume of work exceeds the capacity to do it, and the trade-off therefore has to be made again and again.
Every item carries a description, a rank and, for those at the top, a size estimate. The list has no approved final version: its validity rests on the date of its last review. The team consults it to decide what it takes on next, stakeholders to see what is imminent, what is further off and what may never be worked on at all.
The technique covers the upkeep and the ordering of the backlog. Backlog refinement is the continuous activity that splits an item and details it until it can be worked as it stands. The two often run in the same session and confusing them is expensive. A team that spends its review splitting the top three items never reorders the rest, and the bottom of the backlog goes stale.
Usage
When to use it
- Demand lastingly above capacity: more known items than the team can handle.
- Priorities that will move along the way: the current order decides what gets worked next.
- A permanent inflow: defects, change requests and maintenance arrive unannounced and are weighed against everything else.
- Mixed work to be weighed together: user stories, non-functional requirements, defects and documentation tasks in a single queue.
- Capacity freeing up in bursts: the team pulls the next item as soon as a slot opens.
When not to use it
- A contractual scope frozen and sequenced before execution: a scope statement and a project schedule are the better instruments.
- A handful of items with no inflow: a task list is enough; the review cadence costs more than it returns.
Description
What goes into the backlog
An item goes into the backlog if it has value for a stakeholder. The criterion is broad by design. So is the list of item types: use cases, user stories, functional and non-functional requirements, design elements, customer orders, change requests, defects, planned rework, maintenance, risk items, down to "give a presentation" or "write a document".
The most widespread mistake is to treat the backlog as a feature list. A team that puts only user stories on it weighs its defects, its technical debt and its documentation obligations in a parallel queue that never competes with the product. Maintenance therefore comes after everything else because it was never put in competition with anything. Item tracking stays useful for carrying the life cycle of a defect or an open issue; the backlog carries the trade-off between that defect and everything competing with it.
The right to add an item is decided explicitly. Three forms occur: a single person holds the authority to add, a committee decides by consensus or the responsibility is delegated to the business analyst. Automatic entry rules come on top, for instance the obligation to record any major defect as soon as it is qualified. Under formal, auditable change governance, the backlog feeds the process, but the change request register stays the document of record. A team that has never settled this question has settled it by default: everyone adds and the backlog becomes the place where you file what you do not want to forget.
The detail concentrates at the top
Items near the top are described in detail, with an estimate of size and complexity reliable enough to derive a cost and an effort from it. That size is expressed in a relative unit, in points or in t-shirt sizes depending on the team. An item added far from the top gets the minimum of work needed to understand what it involves. When its priority rises, it is reviewed, possibly broken down and estimated more closely.
This concentration is what makes the technique workable at any size: elaborating three hundred items to the same level of detail takes weeks, produces figures that are out of date before they are used and feeds a decision that bears on the first few items only. The corollary is a team discipline: refusing to detail an item at the bottom as long as its rank does not move.
The cost and the effort consumed by finished items serve to recalibrate the estimates of those that remain: a team that regularly delivers at twice its estimate learns that gap and carries it over to the rest of the backlog. Estimation thus becomes a recurring act, on the model of rolling wave estimation.
Priority, in two stages
Items are prioritised relative to one another. That relative priority moves: stakeholder needs change, dependencies appear between items and the rules of backlog management weigh on the order too.
On entry, prioritisation is coarse: high, medium or low. Items in the high group are reviewed more often, since they are the candidates for the next committed work. To separate them, a finer ranking applies inside that group, for instance a numeric rank based on a measure of value. BABOK describes this mechanism without naming a method. MoSCoW, WSJF and cost of delay are possible implementations of it; cost of delay, formalised by Reinertsen, lends itself to a rank replayed at every review, because it produces a number that is comparable across items of different kinds.
The move from group to rank is the difference between grouping and ranking. The first sorts items into a few shared categories, with no order inside a category. The second gives each item a unique position. A backlog lives with both: grouping across the whole, ranking on the head of the list.
BABOK speaks of prioritisation and of relative priority. The Scrum Guide describes the Product Backlog as an ordered list and does not use the vocabulary of prioritisation: the Product Owner answers for that order. The two vocabularies point to neighbouring practices without being interchangeable. Using the word of the framework under discussion avoids ambiguity in the room.
Selecting items and taking them out
When capacity frees up, the team reviews the top of the backlog and selects according to that capacity, the dependencies between items and what it understands at that moment of their size and complexity. Rank guides the selection without dictating it: an item at rank 2 whose prerequisite is not ready gives way to the next one.
An item leaves the backlog for two reasons: it is finished or a decision has been taken to stop working on it. A removed item can come back. BABOK gives four grounds: a significant change in stakeholder needs, work that runs longer than estimated, other priority items overrunning their own estimate or a delivered product carrying defects. Removing an item is therefore a cheap decision: you can purge without hesitating and put the item back later.
What does the size of the backlog tell you?
The number of items is tracked over time. A backlog that grows signals a rise in demand or a fall in productivity; a backlog that empties signals a fall in demand or an improvement in the production process. The curve alone does not say which one applies. The cause is looked for at every inflection, on the inflow side as much as on the delivered capacity side.
An organisation often keeps two: an overall backlog gathering everything that is known and a second one, cut down to what will be delivered within a short horizon, fed by the first. The distinction earns its keep when the two audiences differ, a portfolio committee on the first and a delivery team on the second. It is paid for in synchronisation work: an item promoted into the short list has to leave the queue of the overall list, failing which it exists twice and is estimated twice.
Three traps that drain a backlog of its meaning
The first is the backlog turned into a store room: past a certain volume it becomes heavy to keep. The review no longer goes past the first twenty items. An item added six months ago with three words of description is understood by nobody. The loss of information is all the faster because the detail down there is thin by construction. The answer is to accept removal: an item that two successive reviews failed to explain is taken out, at the price of coming back properly described.
The second is the missing cadence. The periodic review of the whole holds everything else together, since that is where changes of need translate into changes of rank. With no planned interval, the review shrinks to preparing the next iteration and the order at the bottom sets solid.
The third is the order nobody answers for. A rank produced by a round of the table, with no criterion written down, is contested at every session and replayed at every change of interlocutor. Naming who arbitrates and writing down the criterion costs a few minutes per review and makes the order defensible the day someone asks why their item went behind another.
AI considerations
Three uses earn their place on a large backlog. The first is detecting semantic duplicates: spotting that two items worded differently describe the same need, before both are estimated and then built. Over several hundred rows accumulated in two years, that is work no human review carries out. The second is ageing analysis: surfacing the items no review has touched for N cycles, so that a person decides whether to take them up in detail or remove them. The third is drafting a first detailed description and acceptance criteria when an item moves from the bottom towards the top, out of what the item already carries. An estimate range derived from historical throughput on comparable items is added where useful; the business analyst reworks that text and has it validated.
The machine does not reorder: rank expresses value for stakeholders and a trade-off between them, which cannot be inferred from the text of the items. It neither merges nor deletes a presumed duplicate without human confirmation, because an item that looks redundant can reopen for reasons the text does not contain. It delivers no estimate without showing what that estimate rests on, failing which nobody can defend it in review. Finally, the content of the items is project content like any other: the backlog of a self-service portal carries benefit labels, case identifiers and descriptions of defects touching health data. The tool that processes these texts falls under the same data protection requirements as the system itself.
Examples
The position of an item commands its level of detail and of estimation. The backlog below belongs to the team modernising the self-service portal of a health insurer.
Backlog management · a single queue of items
Self-service portal, state at the review of 12 March
| Rank | Item | Type | Priority | Estimate |
|---|---|---|---|---|
| 1 | As an insured person, I upload a receipt for a medical expense from my mobile phone. Acceptance criteria written, formats and size limit fixed. | User story | High | 5 points |
| 2 | The upload answers in under 3 seconds for 95% of requests, measured server side. | Non-functional requirement | High | 3 points |
| 3 | The statement of benefits shows a wrong balance when the deductible is partly reached. Case reproduced, two control accounts. | Defect | High | 2 points |
| – | Request for cover of a treatment abroad. | Use case | Medium | Rough order of magnitude |
| – | Accessible login screen. | Non-functional requirement | Medium | Not estimated |
| – | SMS notification channel. | Change request | Low | Not estimated |
| – | Billing partner API deprecated in 2027. | Risk item | Low | Not estimated |
| – | Documentation of the reimbursement process. | Documentation task | Low | Not estimated |
A user story, a non-functional requirement, a defect, a use case, a change request, a risk and a writing task compete for the same queue and the same head of the list. The statement defect goes ahead of the accessibility of the login screen because it touches an amount displayed to the insured person, a trade-off that two separate queues would never have made possible.
The review of 12 March brought the statement defect into the High group, at rank 3, the day customer service counted eleven calls about the same wrong balance; it dropped the SMS notification back to Low, held at Medium since the autumn, once email proved enough. The request for cover abroad is waiting on two things before it is estimated: confirmation that such treatments fall under basic insurance and the billing partner's answer on the exchange format. As long as those two points are open, splitting it would cost work that has to be done twice; its rough order of magnitude is enough to compare it with the others.
Visualisations
The deliverable is the table itself, written in HTML. The use of the artefact lies in three operations that an image loses: sorting on rank, filtering on a type and rereading a row to justify a position.
The mechanism that produces this table does not fit inside it. The concentration of detail at the top is a spatial property: it shows when the items at the top take up room, with their description and their estimate badge, when those in the middle shrink to a label and when those at the bottom are no more than marks without a tag. Two arrows complete the reading, one leaving the top for selection and the other running back up for the periodic review.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Low | Three decisions and a tool: who has the right to add, at what interval the whole is reviewed, where the list is kept. A spreadsheet is enough to start. |
| Execution | Medium | The periodic review, the reprioritisation, the recalibration of the estimates and the tracking of size are continuous work that grows with the number of items. |
| Documentation | Low | The backlog is its own documentation. |
Tooling
For a small team, a shared spreadsheet or a Kanban board, physical or in a light tool such as Trello, does the job at no cost. The order is the position of the row or of the card, the type is a column or a tag and the review consists of moving cards. Beyond a few dozen items, the absence of history and of filtering makes tracking the size impractical.
At the scale of a product team or a department, Jira, Azure DevOps Boards and their equivalents carry natively what the technique asks for: a rank set by dragging, a typing of items that allows stories, defects and risks to be mixed in a single queue and a throughput history that feeds the recalibration of the estimates. These tools also make ageing measurable, through a query on the date of last change.
When the backlog is fed by formal demand governance, the demand or portfolio modules of a service management platform, ServiceNow for instance, make the link between the intake of requests and the delivery queue. The anti-tool remains the presentation: a backlog in a deck of slides cannot be sorted, cannot be filtered and is wrong the day after its last update.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.2 Backlog Management: the definition of the backlog, the six decisions of its management, the list of item types, the governance of adding, prioritisation in several phases, the concentration of detail at the top, the grounds for removal and reinstatement, the reading of variations in size and the limitations cited.
- Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020), "Product Backlog" section: the Product Backlog defined as an ordered list the Product Owner answers for and backlog refinement presented as an ongoing activity.
- Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing: cost of delay as an economic measure of relative value, usable to separate items within the same priority group.