Kanban and Flow-Based Debt Management
Almost every piece of advice about scheduling technical debt assumes you have sprints. If your team pulls work continuously, "reserve 20% of every sprint" is not a policy -- it is a sentence about someone else's calendar.
This page rebuilds debt management on flow primitives instead: WIP limits, flow efficiency, the constraint, value stream maps, Cost of Delay arithmetic, classes of service, and cumulative flow diagrams. It ends with the same debt item scheduled twice -- once by a Scrum team, once by a Kanban team.
Why "20% of Every Sprint" Falls Apart Without Sprints
The standard advice for funding technical debt work is to carve a fixed slice out of each iteration. It is good advice, and our own sprint planning guide explains how to defend that slice. But it depends on a container that only Scrum provides. The 2020 Scrum Guide defines Sprints as fixed length events of one month or less, and a percentage allocation is meaningful precisely because that container has a known size, a known start, and a known end.
Source: Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020) -- "They are fixed length events of one month or less to create consistency."
A Kanban team has no such container. Work is pulled when capacity frees up, not when a calendar boundary arrives. There is nothing to take 20% of. Teams in this position usually do one of two things, and both fail. They either invent a phantom sprint purely to hold the debt allocation, which reintroduces batching they deliberately removed, or they abandon the allocation altogether and go back to fixing debt only when something breaks.
There is a deeper problem, and it is the most common objection you will hear even from teams that do run sprints: the number is arbitrary. Nobody can say why 20% is right rather than 10% or 35%. It is a heuristic dressed as a budget, and the first time a release is in trouble, an arbitrary number is the easiest thing in the plan to cut. If your only defence of the debt allocation is "the internet says 20%", you will lose that argument every quarter for the rest of your career.
Flow-based management replaces the percentage with something better: a set of standing policies that make debt work structurally necessary rather than politically negotiated. Instead of asking "how much of this iteration do we spend on debt?", a flow team asks three questions continuously.
What is blocked?
A WIP limit turns every blocker into an immediate capacity problem. You cannot start something else to avoid it. The debt that blocks work gets fixed because the alternative is idleness.
Where is the queue?
Flow efficiency and the cumulative flow diagram point at the stage where items wait. That stage is where debt is costing you money, regardless of where it was written.
What does waiting cost?
Cost of Delay divided by duration produces a defensible order. It is arithmetic, not a percentage, so it survives contact with a finance conversation.
None of these require a sprint boundary. All of them work equally well for a Scrum team that wants a stronger argument than "we agreed on a fifth of the capacity."
WIP Limits Are the Primary Debt-Control Mechanism
A work-in-progress limit is not a productivity tool. It is a detector. It converts invisible technical debt into a visible, immediate, unavoidable stoppage.
The Arithmetic: Cycle Time Is WIP Divided by Throughput
Little's Law, proved by John D. C. Little in 1961, relates the three quantities you care about. In its Kanban form it is written WIP = Throughput x Cycle Time, which rearranges to Cycle Time = WIP / Throughput. Throughput is bounded by your team's actual capability, so the only lever you can pull today, without hiring anyone, is WIP. Halve the number of things in flight and you roughly halve the time each one takes. This is why the first intervention on a slow team is never "work faster" -- it is "start less."
Source: Businessmap (formerly Kanbanize), "Little's Law: The Road to Stable and Predictable Systems" -- "In that context, the law is formulated as: WIP = Throughput * Cycle Time"
How Technical Debt Inflates WIP
Debt does not usually announce itself. It expresses itself as items that cannot finish. A change touches a module with no tests, so it waits for a two-day manual regression pass. A migration needs a schema change, so it waits for the one database owner. A pull request sits because only one person understands the module. Each of those items is still "in progress" -- it is occupying a slot, consuming attention at every stand-up, and rotting as the branch drifts from main. Without a limit, the team's response is to start something new, which is exactly the wrong move: it raises WIP, which by Little's Law raises cycle time for everything, including the item that was already stuck.
Source: Kanban University, "The Official Guide to The Kanban Method" -- "Limiting the work that is allowed to enter the system is an important key to reducing delay and context switching which may result in poor timeliness, quality, and potentially waste."
Lowering the Limit Is How You Surface Debt
Here is the mechanism that makes WIP limits a debt tool rather than a scheduling tool. When the limit binds and there is nothing you are allowed to start, the only legal move is to go help finish something already in flight. That forces the team to confront the actual reason the item is stuck -- and the reason is almost always debt. A slow test suite. A deploy nobody can run alone. A module with a single owner. Under an unlimited board, those causes stay hidden behind a comfortable illusion of busyness. Under a binding limit they become the loudest thing in the room, every single day, until somebody fixes them.
This is what replaces the 20% rule. You are not budgeting debt work. You are creating a system in which unfixed debt physically stops feature delivery, so the fix competes on merit at the moment it hurts.
Setting the First Limit Without a Fight
Do not start with a theoretically correct number. Count what is genuinely in flight right now -- including the things everyone forgot were open -- and set the limit one below that count. Run for two weeks. If nothing changes, drop it by one again. Keep going until the limit starts to bind, then stop. The point at which people begin complaining is the point at which the system has begun telling you the truth. Track the four flow metrics from the Kanban Guide while you do it, so the conversation stays about data rather than comfort.
Source: Kanban Guides, "The Kanban Guide, version 2025.5" -- "WIP: The number of work items started but not finished. Throughput: The number of work items finished per unit of time."
Flow Efficiency: Debt Shows Up as Waiting, Not as Slow Typing
Flow efficiency is the ratio between the time work is actively being worked on and the total elapsed time from start to finish. It is the single most persuasive measurement you can put in front of a manager who believes the engineering team is slow, because it reframes the entire conversation. The complaint "our developers take three weeks to ship a small change" becomes the finding "our developers spend two days on a small change and the system queues it for thirteen."
Source: Businessmap (formerly Kanbanize), "The Art of Lean: Monitoring Flow Efficiency" -- "Flow efficiency measures the ratio between value-adding time and the lead time required to complete a process."
A Worked Example
Take one real ticket that recently shipped. Reconstruct its timeline hour by hour from the board history, the pull request, and the deploy log. A typical result on a team carrying meaningful debt looks like this:
| Step | Active time | Wait time | Why it waited |
|---|---|---|---|
| Write the change | 6 hours | 0 | - |
| Wait for review | 1 hour | 3 days | One person understands this module |
| CI run and reruns | 0 | 1.5 days | Flaky suite, three retries |
| Manual regression | 4 hours | 4 days | No integration tests, shared QA environment |
| Release window | 2 hours | 4.5 days | Manual runbook, weekly batch |
| Total | 1.6 days | 13 days | Flow efficiency = 1.6 / 14.6 = 11% |
These figures are illustrative -- run the exercise on your own ticket. But notice what the table does. Every row in the wait column names a specific piece of technical debt, and the debt is now denominated in days of calendar time rather than in adjectives. You are no longer asking for permission to clean up code. You are proposing to recover thirteen days per change.
Measure It Cheaply
You do not need a tool. Add a physical or digital marker to any card that is waiting on something outside the team's control, and record the date it went on and came off. After three weeks you will have a wait-time distribution good enough to argue with. If you want the number continuously, most flow tools compute it from column transitions once you tag which columns are queues and which are active.
Do Not Chase a Benchmark
You will find "typical" flow efficiency figures quoted widely online. We are deliberately not repeating one, because the commonly cited numbers trace back through blog posts rather than to a study anyone can check. Your own baseline is worth more than someone else's average anyway: measure it once, then measure it again after you fix the top wait state, and report the delta.
Theory of Constraints: Debt Fixed Away From the Bottleneck Buys Nothing
This is the idea that explains most disappointing refactors. A team spends six weeks on genuine, high-quality debt reduction, and delivery speed does not move at all. The work was real. It was simply not at the constraint.
Eliyahu M. Goldratt introduced the Theory of Constraints to a wide audience in the 1984 novel The Goal, written with Jeff Cox. Its central claim is that any system has exactly one binding constraint at a time, and that the throughput of the whole system equals the throughput of that constraint. Effort spent strengthening anything else produces no system-level improvement -- it only builds inventory in front of the bottleneck.
Source: Theory of Constraints Institute, "Five Focusing Steps, a Process of On-Going Improvement" -- "Strengthening any link of a chain (apart from the weakest) is a waste of time and energy."
1. Identify
Find the one stage where work piles up. On a board it is the column whose queue never empties. On a CFD it is the band that widens.
2. Exploit
Get everything you can from it for free. Stop the constraint doing anything it does not have to do. Never let it idle waiting on a handoff.
3. Subordinate
Make every other stage run at the constraint's pace. Upstream stages producing faster only create queues and stale branches.
4. Elevate
Only now spend real money. This is where the big debt project belongs, once you know it is aimed at the right thing.
5. Prevent inertia
The constraint moves once you fix it. Go back to step one. The policy that helped last quarter becomes this quarter's bottleneck.
Finding the Constraint on a Delivery Pipeline
In software the constraint is rarely "writing code". It is usually code review, a shared test environment, a manual release process, a security or compliance sign-off, or one person who is on every critical path. Find it by looking for the stage with the longest queue in front of it, not the stage that takes the longest to perform. A step that takes four hours but has nothing waiting is not your problem. A step that takes twenty minutes but has eleven items queued is.
The Refactor That Changed Nothing
A team rewrites a tangled billing module. Code quality improves, the developers are happier, and lead time does not move one day, because every change still waits four days for the shared QA environment. The rewrite was upstream of the constraint. The correct move -- unglamorous, and roughly a tenth of the effort -- was to make the QA environment reproducible. Subordinating to the constraint means the billing rewrite waits until it is either at the constraint or cheap enough to do in the slack the constraint creates.
Value Stream Mapping: Where the Debt Actually Costs Time
Flow efficiency tells you that you are queueing. A value stream map tells you where. It is the technique for drawing every step between a request and its delivery, including the steps nobody owns and the handoffs nobody documented.
Source: Lean Enterprise Institute, "Value Stream Mapping (Lean Lexicon)" -- "Value-stream mapping (VSM) is diagraming every step involved in the material and information flows needed to bring a product from order to delivery."
Run it as a two-hour workshop, not a project. Pick one representative work item that shipped in the last month -- not the best case, not the disaster, the boring middle. Put the team in a room with the ticket history open. Walk backwards from production to the original request and write down every state the item passed through, including the ones that are not on your board.
Record Three Numbers Per Step
Process time (how long the work itself takes), lead time (how long the item sits in that state from arrival to exit), and percent complete and accurate (how often the item arrives in a state where the next person can actually use it without going back). The third number is where debt hides: rework loops rarely appear on a board at all.
Mark Every Handoff
Every time the item changes hands -- team to team, human to system, system to human -- draw a line. Handoffs are where queues form, and queues are where the calendar time goes. A map with nine handoffs and eleven days of wait time will not surprise anyone once it is on the wall, which is exactly why you draw it.
Pick One Step, Not Nine
The map will show a dozen improvable things. Resist. Combine it with the constraint analysis above and change exactly one step -- the one carrying the largest wait time at the bottleneck. Re-map in a quarter. A value stream map that produces a twelve-item backlog has produced more debt, not less.
The output that matters is not the diagram. It is the sentence you can now say to a sponsor: "Of the nineteen calendar days between request and release, we touch the work for two. Eleven of the remaining seventeen sit in one step, and that step is slow for a reason we can name and fix."
Cost of Delay and CD3: Prioritizing Debt With Arithmetic
Cost of Delay is mentioned constantly and operationalized almost never. Here is how to actually run the calculation, with the numbers written out.
Step 1: Price the Waiting, Not the Work
Cost of Delay answers a different question from "what will this cost to build?" It asks what it costs you per unit of time that the thing does not exist. For a feature that is usually forgone revenue. For technical debt it is almost always recurring waste: engineering hours burned on a workaround, incident minutes, support tickets, or a manual step performed every week forever.
Source: Black Swan Farming, "Cost of Delay" -- "Cost of Delay is a way of communicating the impact of time on the outcomes we hope to achieve. More formally, it is the partial derivative of the total expected value with respect to time."
Step 2: Divide by Duration
Cost of Delay alone will always tell you to do the biggest, most painful thing first. That is the wrong answer when capacity is fixed, because the biggest item also blocks everything behind it for longest. CD3 -- Cost of Delay Divided by Duration -- corrects for this, and it is the specific form of Weighted Shortest Job First that most flow teams actually use.
Source: Black Swan Farming, "Cost of Delay Divided by Duration" -- "When using CD3, the priority order of features (or initiatives/projects) is determined by dividing the estimated Cost of Delay by some estimate of duration: the higher the resulting score, the higher the priority."
Source: Scaled Agile, Inc., "WSJF - Extended Guidance, Scaled Agile Framework" -- "Weighted Shortest Job First (WSJF) is a prioritization model used to sequence work for maximum economic benefit. In SAFe, WSJF is estimated as the relative cost of delay divided by the relative job duration."
Step 3: The Worked Arithmetic
Three candidate debt items compete for one team. The dollar figures below are illustrative placeholders -- substitute your own fully loaded hourly rate and your own measured waste -- but the arithmetic and the conclusion are the point.
| Debt item | Cost of Delay per week | Duration | CD3 score |
|---|---|---|---|
| A. Quarantine the flaky test suite (six engineers losing about four hours a week to reruns) | $2,400 | 1 week | 2,400 |
| B. Automate the manual release runbook (three hours per release, plus the batching it forces) | $9,000 | 6 weeks | 1,500 |
| C. Split the shared core library that forces four teams into lockstep releases | $12,000 | 12 weeks | 1,000 |
Intuition says do C first: it is the biggest pain and the loudest complaint. CD3 says the opposite -- A, then B, then C. Compare the total delay cost incurred by each sequence, where each item keeps bleeding until the week it is finished:
CD3 order: A, B, C
- A done at week 1: $2,400 x 1 = $2,400
- B done at week 7: $9,000 x 7 = $63,000
- C done at week 19: $12,000 x 19 = $228,000
- Total delay cost: $293,400
Biggest-pain order: C, B, A
- C done at week 12: $12,000 x 12 = $144,000
- B done at week 18: $9,000 x 18 = $162,000
- A done at week 19: $2,400 x 19 = $45,600
- Total delay cost: $351,600
Same three items. Same team. Same nineteen weeks of work. Sequencing by CD3 rather than by size costs $58,200 less -- about seventeen percent -- and it costs nothing to adopt, because the only thing that changed was the order. That is the argument to bring to a prioritization meeting, and it pairs directly with our prioritization guide.
If You Cannot Estimate in Currency
Score both terms relatively instead, the way SAFe does: give each item a relative Cost of Delay on a 1-2-3-5-8-13 scale and a relative duration on the same scale, then divide. The absolute numbers will be meaningless and the ordering will be almost identical, which is all you needed. Relative scoring also defuses the usual objection that nobody can put a real dollar figure on a test suite -- you are not claiming to, you are only claiming that A hurts more per week than B.
Classes of Service: Scheduling Debt Without a Sprint Boundary
A class of service is an agreed policy for how a particular kind of work item is treated. Kanban University explains it with a road metaphor: some vehicles are allowed through the system preferentially, under rules everybody knows in advance.
Source: Kanban University, "The Official Guide to The Kanban Method" -- "Different types of vehicles such as police cars, fire trucks or ambulance cars may pass through the system preferentially. This is an example for treating defined items in a differentiated manner."
This is the mechanism that replaces the sprint percentage. Instead of reserving a share of a timebox, you allocate a share of your WIP slots by class, and you write the allocation down as a board policy. The policy is enforced continuously, at every pull decision, rather than renegotiated at every planning meeting -- which is precisely why it survives a bad quarter when a percentage does not.
Expedite
Production is on fire. May break the WIP limit. Strictly rationed -- typically one slot, and if two arrive at once, the second one waits. Debt work almost never belongs here, and a team where it does has a bigger problem than scheduling.
Fixed date
A real external deadline: a certificate expiry, a runtime end-of-life, a regulatory date. A surprising amount of debt lands here once you look. An unsupported dependency with a published end-of-support date is a fixed-date item, not an "intangible" one.
Standard
The default. Pulled in CD3 order. Most debt with a measurable weekly cost belongs here, competing with features on the same arithmetic rather than in a separate ghetto labelled "tech tasks".
Intangible
Real cost, no near-term deadline, hard to price. Long-horizon architectural debt lives here. Without a guaranteed slot this class is never pulled, which is exactly how a codebase quietly decays over three years.
Write the Allocation Policy Down
A workable starting policy for a team with six WIP slots, written on the board where everyone can see it:
- At most one slot may hold an Expedite item, and pulling one requires naming what it displaced.
- At least one slot must always hold a Standard-class debt item or an Intangible item. If none is in flight, the next pull must be one.
- Fixed-date items are pulled by date, working backwards from the deadline with a stated buffer.
- Everything else is pulled in CD3 order, features and debt in one ranked queue.
Note what the second rule does. "At least one of six" is arithmetically close to the old 20% heuristic, but it is enforced by a pull rule that binds today rather than by a promise about a two-week aggregate. Nobody has to defend it in a planning meeting because there is no planning meeting -- the board simply does not permit the alternative.
What Technical Debt Looks Like on a Cumulative Flow Diagram
A cumulative flow diagram stacks the count of items in each workflow stage over time. Each coloured band is one stage. Because it plots the whole system rather than individual tickets, it is the fastest way to see structural problems -- and technical debt produces recognisable shapes on it.
Source: Kanban University, "The Official Guide to The Kanban Method" -- "The colored areas in the diagram represent the number of work items within a particular activity in the workflow and how these work items move across all activities, from top to bottom, over time until done."
Source: Businessmap (formerly Kanbanize), "What Is the Cumulative Flow Diagram?" -- "The top line of each band on the cumulative flow chart represents the entry point of tasks in the respective stage of your kanban board, while the bottom one shows when it leaves it."
Read it two ways. Vertically, the thickness of a band is how many items are sitting in that stage right now. Horizontally, the distance from an item's entry into the first stage to its exit from the last in-progress stage approximates cycle time. Once you know that, the diagnostic patterns are easy to spot.
| What you see | What it means | Debt usually behind it |
|---|---|---|
| One band steadily widening while the others stay flat | That stage is the constraint. Arrivals exceed departures. | Slow or manual verification, single-owner review, a shared environment |
| The whole chart drifting wider over months | Cycle time is growing across the board. | Compounding debt: every change now touches more surface than it used to |
| A "Done" line that climbs in stair steps rather than smoothly | You are releasing in batches, not flowing. | Manual release process, expensive deploys, a release window |
| A "Blocked" or "Waiting" band that never returns to zero | There is a permanent external dependency. | Coupling to another team's release train, an unowned service, a missing API |
| A band that repeatedly shrinks and re-swells | Items are moving backwards. This is rework. | Missing tests, unclear acceptance, a fragile module that breaks on every change |
The last row is the one to watch for. Rework does not appear in velocity, story points, or a burndown -- all of those treat a re-opened item as new work. A CFD shows it as an oscillation, and oscillation is the clearest quantitative fingerprint of quality debt you will get without instrumenting the codebase. See measuring technical debt for the code-level metrics that pair with these flow signals.
The Same Debt Item, Scheduled Two Ways
The item: "The orders service has no integration tests. Every change to it requires two days of manual regression before release." Here is how it actually gets scheduled under each system.
The Scrum Team
- An engineer raises it at refinement after being burned by it for the third time.
- It is estimated at 8 points against a velocity of about 30, so it is a quarter of a sprint.
- It enters the product backlog and is immediately outranked by committed feature work.
- It is proposed for the 20% allocation. Two sprints in a row the allocation is spent on urgent bugs.
- By sprint four the item is split into three smaller items to fit, and only the first is pulled.
- Elapsed time from raise to first line of code: roughly eight weeks. During that time every change to the orders service paid the two-day tax.
The Kanban Team
- The manual-regression column has a WIP limit of two. It is full for the third week running.
- The CFD shows that band widening while everything upstream stays flat: this stage is the constraint.
- Flow efficiency on recent items is measured. Manual regression accounts for four of the fourteen calendar days.
- Cost of Delay is calculated from the recurring two-day tax across the change rate. Duration is estimated. CD3 puts it above two of the queued features.
- It is classified Standard, and the "at least one debt slot" policy means it is pulled the next time a slot frees.
- Elapsed time from detection to first line of code: days, and the trigger was a board policy rather than an engineer's persuasiveness.
| Dimension | Scrum | Kanban / flow |
|---|---|---|
| What triggers the work | A person advocates for it in refinement | A WIP limit binds, or a flow metric degrades |
| Sizing | Story points, relative to other backlog items | Duration estimate, used only as the CD3 denominator |
| Scheduling unit | The sprint | The free WIP slot |
| Commitment point | Sprint planning, up to two weeks away | The moment of pull, deferred until the last responsible moment |
| What protects the debt budget | A percentage agreement, renegotiated each sprint | A written pull policy plus a class-of-service allocation |
| Failure mode | The allocation is quietly spent on urgent work every sprint | The expedite lane is abused until every item is expedite |
| Best argument to leadership | Predictable capacity for maintenance | Measured wait time and a CD3 sequence with the money written out |
The honest summary: Scrum gives debt work a reserved seat that is easy to take away. Flow gives it no seat at all and instead makes the system refuse to run while the debt is unfixed. The second is harder to set up and far harder to erode.
Related Resources
Sprint Planning
The Scrum-side counterpart to this page: how to reserve capacity for debt inside a timebox and defend it when the sprint gets tight.
Prioritization
Ranking frameworks for debt work, and where CD3 fits alongside impact-effort scoring and the technical debt quadrant.
Measuring Tech Debt
Code-level metrics that pair with flow metrics, so you can show both the symptom on the board and the cause in the repository.
Frequently Asked Questions
Replace the percentage with two written board policies. First, a class-of-service allocation: at least one WIP slot must always hold a debt item, and the next pull must be one if none is in flight. Second, a CD3 ranking so debt and features compete in a single queue on the same arithmetic. A percentage of a timebox is renegotiated every planning meeting and loses; a pull policy binds at the moment of every pull decision and is far harder to erode.
Debt expresses itself as items that cannot finish: a change waiting on a manual regression pass, a pull request waiting on the only person who knows the module, a branch waiting on a flaky test suite. Without a limit the team starts something new, which raises WIP and, by Little's Law, raises cycle time for everything. With a binding limit there is nothing legal to start, so the only move is to go unblock the stuck item and confront the debt causing it. The limit converts invisible debt into an immediate, unavoidable capacity problem.
Flow efficiency is active working time divided by total elapsed time from start to finish. It is persuasive because it reframes the argument. A manager who believes "the developers are slow" is looking at three weeks of calendar time. Flow efficiency shows that two of those days were work and the rest was queueing on a slow test suite, a single reviewer, a shared environment, and a weekly release window. That turns a performance conversation into a system conversation, and every wait state on the list names a specific piece of debt with a cost in days.
Because the throughput of a delivery pipeline equals the throughput of its constraint. Improving any other stage just moves work into the queue in front of the bottleneck faster. This is why a team can complete a genuine, well-executed refactor and see lead time fail to move at all: the rewrite was upstream of the real limit, which was the shared QA environment or the single approving reviewer. Identify the constraint first, exploit and subordinate before you elevate, and re-check after every fix because the constraint moves once you relieve it.
Estimate the recurring waste the debt causes per week, in money or in engineering hours: reruns, manual steps, incident time, support load. That is the Cost of Delay. Estimate how long the fix takes. Divide the first by the second. Rank descending. The result routinely inverts intuition, because the biggest, most painful item is usually also the longest and therefore blocks everything behind it. If you cannot produce currency estimates, score both terms on a relative 1-2-3-5-8-13 scale as SAFe does with WSJF; the absolute numbers are meaningless but the ordering is nearly identical, and ordering is all you needed.
Four signatures. A single band widening while others stay flat is the constraint, usually manual verification or single-owner review. The whole chart drifting wider over months is compounding debt, where each change now touches more surface than it used to. A stair-stepped completion line is batched releasing caused by an expensive manual deploy. And a band that repeatedly shrinks then re-swells is rework, which is the clearest fingerprint of quality debt: velocity and burndown charts hide rework by counting a reopened item as new work, but a CFD shows it as an oscillation.
Stop Budgeting Debt. Start Measuring the Queue.
Measure one ticket's flow efficiency this week, find the constraint, and run the CD3 arithmetic on your top three debt items. That is a better argument than any percentage.