A backlog is an ordered list of everything the work might include, held in the order it would be done if nothing changed. The order is part of the content rather than a view of it, and that is the property that separates a backlog from a list of requirements.
Detail is distributed unevenly on purpose. Items near the top are small, clear and ready to be worked on. Items near the bottom may be a phrase, because writing detail for work that may never happen, or that will be understood differently by the time it does, is effort spent on a guess.
What an item carries
An item needs enough for the people building it to know what is wanted and to recognise when they are finished. In practice that is a description, a size, and acceptance criteria.
Acceptance criteria do most of the work. They are the conditions that have to hold for the item to be accepted, written before the work starts and specific enough to be checked rather than argued about. An item described as "the search should be fast" is a preference. An item whose criteria say results return within two seconds for a catalogue of a million records is a target somebody can build against and somebody else can verify.
The user story format puts the beneficiary and the purpose in the sentence, so that a reader knows who wants this and why. That is genuinely useful for functionality with a user, and it becomes a costume when applied to a database upgrade. Use it where it carries meaning.
Refinement is continuous, not an event
Refinement is the ongoing work of breaking large items down, adding detail to items approaching the top, revising sizes as understanding improves, and removing items that no longer earn a place.
It is continuous because the top of the backlog is always moving. Work leaves the top every cycle, which promotes the next set of items into the zone where they need to be ready, and the readiness has to arrive before the planning session rather than during it.
A backlog that is refined only in a scheduled meeting tends to produce planning sessions that turn into analysis sessions, because the items being planned are being understood for the first time. The symptom is a planning session that overruns and a cycle that starts with less agreement than it appeared to have.
Ordering is a decision about value, cost and risk
Several techniques exist, and the exam expects familiarity with what each one optimises rather than mastery of any.
| Technique | How it orders | Where it fits |
|---|---|---|
| Value against effort | Highest benefit for lowest cost first | A quick first pass, and a reasonable default where the items are comparable |
| MoSCoW | Must have, should have, could have, will not have this time | Fixed date work with a negotiable scope, since it names what may be dropped in advance |
| Weighted shortest job first | Cost of delay divided by size, largest first | Where several items are valuable and the cost of waiting differs sharply between them |
| Kano analysis | Separates expected features from those that delight | Product work, where satisfying a basic expectation and adding an attraction are different investments |
| Risk first | Highest uncertainty first, regardless of value | Early in work where a technical unknown could invalidate the plan, so learning is the return |
Risk first deserves particular attention, because it is where adaptive ordering diverges from intuition. Building the most valuable item first is obvious. Building the most uncertain item first is what stops a project discovering in month eight that something assumed to be routine is not possible, and the value of doing so is information rather than deliverable.
The backlog and the work breakdown structure
Both decompose the work, and they are not the same artefact.
A work breakdown structure is a hierarchy of deliverables covering the whole of an agreed scope, and the hundred per cent rule says it contains everything and nothing more. A backlog is a flat ordered list, deliberately incomplete at the bottom, that changes without a change request.
Hybrid arrangements often carry both. The structure holds the contracted or funded scope at a level a sponsor cares about, and one of its work packages is delivered from a backlog underneath. That works as long as everybody understands which artefact is the commitment and which is the current plan for meeting it.
Emergent scope is not scope creep
An adaptive backlog changes constantly, so the usual test for scope creep does not apply. Something has still gone wrong when the total keeps growing while the date and the budget stay fixed, and the difference is where the change came from.
Scope discovered through feedback, and then ordered against everything else so that something else drops out, is the mechanism working. Scope added because a stakeholder asked directly and nobody reordered anything is the same failure as uncontrolled change in a predictive project, wearing different clothes.
The control is that the list stays ordered and the capacity stays honest. Anything can be added at any position, and adding it at the top means something at the bottom will not be reached.
Where each syllabus puts it
Scrum names it the product backlog, makes one person accountable for its ordering, and requires that the ordering be respected by everyone. Extreme Programming uses stories on cards with the customer choosing what goes into the next release. Kanban tends to keep a shorter queue in front of the work with a replenishment conversation on a cadence of its own.
PMI treats the backlog as a generic artefact of adaptive delivery. Exam questions usually turn on who is entitled to reorder it, what happens when somebody bypasses the order, and how a fixed date is met by moving scope rather than by moving the date.