Techniques BABOK Guide v3, 10.2
Backlog Management
In short A backlog is an ordered list of work still to be done. Backlog management means recording, ordering, refining and updating that list so that the team always works on the most valuable items, and everyone can see what comes next.
Based on: IIBA, BABOK® Guide v3, technique 10.2 “Backlog Management”.
On this page
What it is#
The BABOK® Guide describes backlog management as a systematic way to record, track and prioritize remaining work when there is more work than capacity to do it. It is most associated with agile delivery, but it works in any setting where demand exceeds supply.
Key ideas from the BABOK Guide:
- Items can be any kind of work: use cases, user stories, functional and non-functional requirements, designs, customer requests, risks, change requests, defects, support tasks. Who may add items is a decision: one person, a group, or delegated to the analyst. Some item types, such as serious defects, may have their own rules.
- The top of the backlog holds the highest value. Ordering is often done in steps: a rough sort into high, medium and low, then a finer ranking within the high group.
- Detail is proportional to position. Items near the top are refined and estimated carefully; items lower down get just enough detail to understand their size. As an item rises, it is refined and often split.
- The backlog changes constantly. New items are added and placed relative to existing ones; finished or abandoned items are removed; removed items can come back if needs change, an item turns out larger than thought, other work is delayed, or defects appear.
- There may be more than one backlog, for example a product backlog and a backlog for the next iteration.
- Size is a signal. A growing backlog may mean rising demand or falling throughput; a shrinking one may mean falling demand or a better process.
When to use it#
- When requirements emerge and change over time, and you deliver in increments.
- When many stakeholders compete for the same team’s capacity.
- When you need a simple way to show what will happen soon, later, or probably never.
When not to use it, or what to add: a backlog is not a substitute for a shared understanding of scope; pair it with Scope Modelling or a story map so people can see the whole. For tracking open issues, questions and decisions rather than work, use Item Tracking. For one-off delivery with fixed, stable requirements, a baselined specification may be simpler.
How to do it#
- Agree what goes in and who decides. Define item types, who can add items, who owns the order (often a product owner), and any special rules, for example “critical defects go straight to the top”.
- Capture items consistently. Each needs at least a short title, a description of the need or value, and a link to its source or supporting detail.
- Order the backlog. Sort roughly into high, medium and low; then rank the high group one by one using agreed factors such as value, risk, urgency and dependencies (see Prioritization).
- Refine the top. For the next few iterations’ worth of items, add acceptance criteria, resolve questions, split large items and estimate them. Leave lower items light.
- Update continuously. Add new items in the right place, remove done or rejected ones, and reorder after every review with stakeholders.
- Use feedback. Compare estimates with actual effort on finished items and adjust future estimates.
- Watch the trend. Track the backlog’s size and age over time and discuss what changes mean.
Example#
At The Workshop (a fictional chain of 12 bike-repair shops), the outside development team works in two-week iterations. The top of the product backlog after the first planning session:
| Order | Item | Type | Detail level |
|---|---|---|---|
| 1 | Customer books a repair slot online | User story | Refined, estimated, acceptance criteria agreed |
| 2 | Front desk sees all online bookings in one calendar | User story | Refined, estimated |
| 3 | Booking page loads quickly on mobile phones | Non-functional requirement | Refined, measurable target agreed |
| 4 | Supplier ordering interface may not be ready this year | Risk | Owner assigned, mitigation discussed |
| 5 | Customer receives “repair finished” message | User story | Rough estimate only |
| 6 | Parts ordering from one central screen | Epic | Title and goal only; to be split later |
When the owner asks for a “waiting for parts” notification, the analyst adds it as a new story and places it just below item 5, because it depends on the notification service built for that story.
Common mistakes#
- Treating the backlog as a dumping ground → review and prune regularly; remove items nobody will defend.
- Detailing everything up front → refine just in time; detail on low items goes stale.
- No clear owner of the order → name one person accountable for the ranking, informed by stakeholders.
- Items too terse to understand later → link each item to its source and supporting detail, or information will be lost over time.
- Features only → include non-functional requirements, risks, defects and technical work, or they will surprise you later.
- One huge, long backlog → split into product and iteration backlogs, and group items by theme or goal; long lists are hard to manage.
Checklist#
- Item types, entry rules and the owner of the order are agreed.
- Every item states the need or value and links to its source.
- Top items have acceptance criteria and estimates; large ones are split.
- The order reflects agreed factors, not the loudest voice.
- Non-functional requirements, risks and defects are in the backlog.
- The backlog is reviewed with stakeholders at a fixed rhythm.
- Backlog size and age are tracked and discussed.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.2 “Backlog Management”.