An improvement backlog is a ranked list of the process and product improvements surfaced during delivery, prioritized and scheduled like any other portfolio work. It is one of the named outputs of the Learn practice: the place where retrospective actions, operational pain, and the fixes a team kept deferring under delivery pressure go to compete for real capacity. The word doing the work in that definition is "ranked". A list of improvements nobody has ordered is a list of intentions.
How does an improvement backlog work?
It works by putting improvements into the same queue, under the same limits, as delivery work, so that choosing one is visibly choosing against something else. Each item carries four things: what is wrong now, what changes if it is done, roughly what it costs, and who owns it. That is enough to rank, and it is deliberately less than a business case. An improvement that needs a business case is an initiative, and it belongs in Align with the other candidates.
Items arrive from four places, and it is worth recording which:
- Team retrospectives, which mostly produce process improvements.
- The operational dashboard, which produces stability and product improvements when a threshold keeps being crossed.
- Support and operations, which produce the manual workarounds people have quietly absorbed into their week.
- The value realization review, which produces the adoption and design fixes standing between a delivered feature and the objective it was approved on.
Recording the source tells you where the system is generating friction. If eight of the top ten items came from support, the problem is in the hand-off rather than in the sprint.
Why do retrospective actions stall in retrospective notes?
Because a retrospective produces commitments without capacity, and nothing downstream is obliged to honor them. The team leaves the room agreeing to fix something, then returns to a sprint whose commitments are visible to management while the improvement is visible only in a document the team wrote for itself.
Three mechanisms do most of the damage:
- The action needs someone outside the team. Much of what a delivery team wants improved sits with another team, with procurement, or with whoever owns an upstream system. Inside the retrospective it looks like an action item. Outside it, it is a request with no standing.
- It competes invisibly. Sprint work has a goal, a board, and a review. The improvement has a bullet. When the week compresses, the invisible item is the one that goes.
- Nobody reads the notes again. By the third retrospective the same observation appears for the third time, and the team learns that raising it changes nothing. That is the point at which retrospectives start to shorten.
Moving the item out of the notes and into a backlog that leadership actually ranks is what fixes all three at once. It gives the item an owner with standing, makes the competition explicit, and puts it somewhere that is read between retrospectives.
What does a good improvement backlog look like?
There is one list for the portfolio rather than one per team, because team-local lists recreate the invisibility problem for anything that crosses a boundary. Each item is written as a concrete problem and the change expected if it is fixed: "Build pipeline takes 40 minutes, blocking same-day fixes" beats "improve CI". Items that turn out to be weeks of work move to Align as initiatives instead of clogging the list.
Above all, it is ranked by the people who own the capacity, in the same room that ranks delivery work. An improvement backlog ranked only by the teams that raised the items has no claim on anything. Ranked alongside delivery work, it is subject to the same trade-off as everything else, and capacity is actually set aside for the top of it. The sign it is working is that items leave the list, either done or explicitly closed.
What does an improvement backlog look like in practice?
Picture a five-team insurance IT group that starts one after a release where three separate teams each reported waiting on the same environment. The first pass holds 44 items. At the top, once ranked, are a shared test environment that teams book by email and collide over weekly, a policy import that fails on one carrier format and is fixed by hand, release notes assembled the night before each release, low adoption of a new claims portal, and a missing on-call runbook for two new services.
Two things come out of the first ranking. The environment problem has appeared in three separate retrospectives over four months without moving, because no single team can fix it and no forum exists where all three are in the room. The portal adoption item is not a process improvement at all: it is the reason an initiative is about to fail its value review, and it goes straight back into the delivery plan rather than into a spare capacity slice.
What goes wrong with improvement backlogs?
It becomes a graveyard. A list that only grows teaches people that adding to it is pointless. Cap it. If an item has sat below the line for two quarters, close it and say so.
Everything is ranked high. Improvements raised by the loudest team float to the top. Rank against the same criteria the portfolio uses for anything else: what changes, for whom, and at what cost.
No reserved capacity. Without a standing allocation, improvements are funded out of whatever slack appears, and slack does not appear.
Mixing sizes. A list holding both "fix the runbook" and "replace the integration platform" cannot be ranked usefully, because the two are decided by different people with different authority.
No owner per item. An improvement with no name against it is a wish. Ownership here works the same way it does for a cross-team dependency in Deliver: one name, or it waits.
Improvement backlog vs product backlog vs technical debt register
The three overlap in content and differ in who ranks them and against what.
| Improvement backlog | Product backlog | Technical debt register | |
|---|---|---|---|
| Holds | Process and product improvements found in delivery and operations | Features and changes for one product | Known shortcuts and their consequences |
| Ranked by | The portfolio, against portfolio capacity | The product owner, against product value | Usually nobody, which is the problem |
| Scope | Crosses teams and systems | One product | One codebase or platform |
| Typical failure | Grows without being worked | Grows without being cut | Becomes a document rather than a queue |
| Ends up where | Scheduled work, or explicitly closed | A release | Either the improvement backlog or a rewrite |
A product backlog is not a substitute, because most of what a delivery retrospective surfaces is not about one product: environments, hand-offs, approvals, and the way work arrives. Those items have nowhere to go on a product backlog, so they go nowhere.
A technical debt register is not a substitute either, and it is better understood as an input. A register describes a condition; a backlog schedules a response. Registers that never feed a ranked queue are how a team can document the same debt for three years and still be surprised by it. Merge the register into the improvement backlog at the point where an item has a cost, an owner, and a reason to be done now.
The related vocabulary is collected in agile portfolio management terms. Putting a first ranked improvement backlog in place, with reserved capacity behind it, is part of a PPM4Agile implementation.