Kanban

Definition: Kanban is a pull-based method for managing knowledge work that makes the invisible workflow visible, caps the amount of work allowed in progress at each stage, and manages the resulting flow using empirical metrics. It originated as a signalling system in the Toyota Production System, where a physical card (kanban, roughly “signboard”) authorised the replenishment of a part only when downstream consumption created demand. Applied to software, it is a change-management method layered onto whatever process you already run — it prescribes no roles, no iterations, and no ceremonies. Its mathematical core is Little’s Law, which says that reducing work in progress reduces the time each item takes to finish.

How It Works

The Board as a Model of the Real Workflow

A Kanban board is not a to-do list with columns. It is a model of the actual value stream — the sequence of states a work item genuinely passes through between “someone asked for this” and “a user is getting value from it.” The first act of adopting Kanban is honest observation: watch several real items travel through the system and draw the states you actually observe, including the ugly ones.

Most teams’ first board is wrong in a specific way: it has three columns (To Do / Doing / Done) and hides everything interesting inside “Doing.” A useful board separates the states where work is being actively worked from the states where work is waiting:

Column type	Example	What it reveals
Active state	`In Development`, `In Review`	Where capacity is consumed
Queue / buffer	`Ready for Review`, `Ready to Deploy`	Where items sit idle accumulating age
Commitment point	Boundary of `Ready`	Where the team promises to finish an item
Delivery point	Entry to `Done`	Where value reaches the customer

Splitting a stage into Doing and Done sub-columns is the single highest-value board refinement. Development — Done means “development finished, nobody has picked it up for review.” That queue is pure waiting time, and it is invisible on a naive board. Once visible, it is usually shocking: teams routinely discover items spend 70–80% of their calendar life in queues, not in hands.

A realistic board, with the limit written into every column header:

The backlog is deliberately unlimited — it is not part of the system, it is the demand outside it. Everything from Ready rightward is inventory the team owns, and every one of those columns carries a number. Note that Ready for Review gets a limit too: queues need caps just as much as active states, and an uncapped review queue is where most software boards actually break.

Two more elements complete the board. Swimlanes partition rows by class of service or work type — an “Expedite” lane for production incidents, a “Standard” lane for features, a “Maintenance” lane for chores. Card design carries the information needed to make a pull decision without opening the ticket: item type, age in current column, blocked flag, and who is working it.

WIP Limits and the Pull Signal

A WIP limit is a hard number written at the top of a column: In Development (3). It means at most three items may occupy that column, counting both sub-columns. It is not a target, a goal, or a suggestion. It is a constraint that makes the system push back.

The pull mechanic follows directly. Nobody assigns work. When a developer finishes an item, they look rightward first — is there anything downstream I can help finish? — and only then look leftward to pull a new item from the upstream queue, and only if their column has spare capacity under its limit. The signal to start something new is the completion of something else, never the arrival of a request or the availability of a person.

This inverts the default instinct. Under push, work is assigned when it arrives, and idle people are the thing to be avoided. Under pull, idle work is the thing to be avoided, and an idle person is a signal to go help clear a downstream bottleneck. A blocked board is not a failure of the board; it is the board doing its job — telling you the constraint’s location loudly enough that you have to deal with it.

Choosing an initial limit: a common heuristic is roughly one item per person minus a bit, so a five-person team might start with a total board WIP of 4–5 and per-column limits summing to that. Then tighten. The limit is correct when the board occasionally stalls and forces a conversation — that is exactly the feedback the constraint exists to produce.

Pull versus Push, and the Toyota Lineage

At Toyota, an upstream station produced a part only when it received a kanban card returned from downstream. No card, no production. The card count physically capped inventory between stations. The insight transferred to software is that half-finished work is inventory, and inventory in a software system is worse than inventory in a factory: it depreciates (requirements go stale), it hides defects (an untested feature’s bugs are unknown), and it consumes carrying cost (merge conflicts, context re-loading, status reporting).

The push loop has no feedback edge — that is the whole problem. Nothing in a push system tells the front of the pipeline to slow down, so queues grow without bound until something external (a deadline, a crisis, an exhausted team) intervenes. The pull loop closes on itself: the rate of starting is mechanically tied to the rate of finishing.

The Six Core Practices

David Anderson’s formulation gives Kanban six practices. They are not a sequence to complete but dimensions to deepen continuously.

#	Practice	What it means concretely
1	Visualise	Board mirrors the real workflow, including queues and blockers
2	Limit WIP	Numeric caps per column, enforced by refusing to pull
3	Manage flow	Watch cycle time, throughput, aging; attack the bottleneck
4	Make policies explicit	Written pull criteria and entry/exit rules per column
5	Implement feedback loops	Standup, replenishment, delivery, and operations reviews
6	Improve collaboratively	Change driven by data and models, not opinion

Practice 4 is the one teams skip and the one that decides whether the system works. “Make policies explicit” means writing down, visibly on the board, what specifically qualifies an item to move: what must be true to pull into Development, what Review requires, what “done” means. Without explicit policies, every column transition is a negotiation and the board’s information is fiction. It connects directly to Definition of Done and to the entry criteria a Code Review and Static Analysis process depends on.

Kanban’s feedback loops, or cadences, are decoupled from each other — which is the key structural difference from iteration-based methods. Replenishment (deciding what enters the board) might happen weekly. Delivery might happen continuously. The retrospective-equivalent operations review might happen monthly. Nothing forces them into a single rhythm.

Managing Flow: Blockers and Aging

Two daily disciplines make flow management real rather than decorative.

Blocker management. A blocked card gets a visible marker and a date. Blockers are counted, categorised, and reviewed — “we were blocked by the platform team’s API 6 times this month, averaging 3.1 days” is an actionable fact; “things keep getting stuck” is not. Blocker clustering analysis is often the single highest-leverage improvement input a team has.

Work item aging. Age is how long an item has been in progress right now, and it is the only flow metric available while an item is still unfinished. Cycle time tells you about the past; age tells you about the item burning on your board today. The standup question becomes “which item is oldest and what does it need?” rather than a round of status updates. If your 85th-percentile cycle time is 9 days and a card is on day 12, that card is an exception and needs intervention now, not at delivery.

Little’s Law and the Mathematics of WIP

This is what separates Kanban from “we have a board with columns.”

The Law

Little’s Law is a theorem from queueing theory, proved by John Little in 1961. For any stable queueing system observed over a sufficiently long interval, the average number of items in the system equals the average arrival rate multiplied by the average time an item spends in the system. Rearranged for flow management:

$\text{Cycle Time} = \frac{\text{Work in Progress}}{\text{Throughput}}$

Where:

Term	Definition	Unit
Work in Progress (WIP)	Items started but not finished, counted at an instant	items
Throughput	Items finished per unit time	items/week
Cycle Time	Average elapsed time from start to finish	weeks

The remarkable property is its generality. It assumes nothing about the arrival distribution, the service distribution, the queue discipline, or the number of servers. It requires only that the system be stable — that over the observation window, arrivals roughly equal departures and no work is created or destroyed inside the system.

The Numeric Example

A team of five finishes 10 items per week and, at any given moment, has 20 items in progress.

$\text{Cycle Time} = \frac{20 \text{ items}}{10 \text{ items/week}} = 2 \text{ weeks}$

Every item takes, on average, two weeks from start to finish. Now the team imposes WIP limits summing to 10 and stops starting new work until the board drains to that level. Assume — and this is the crucial assumption — throughput stays at 10 items per week.

$\text{Cycle Time} = \frac{10 \text{ items}}{10 \text{ items/week}} = 1 \text{ week}$

Cycle time halved. Nobody worked faster. Nobody worked longer. The team simply stopped starting so many things at once. The same 10 items per week come out the far end; each one just spends half as long inside the system.

Extend the table to see the shape of the relationship:

WIP	Throughput	Cycle Time	Items delivered in 4 weeks
40	10/wk	4.0 weeks	40
20	10/wk	2.0 weeks	40
10	10/wk	1.0 week	40
5	10/wk	0.5 weeks	40

The delivery column is identical. High WIP buys you nothing in total output; it buys you longer waits, staler feedback, and later discovery of defects. This is the counterintuitive heart of it: doing fewer things at once makes each thing finish faster, at no cost in total volume.

Why Throughput Usually Rises When WIP Falls

The table above held throughput constant to isolate the effect. In practice, cutting WIP typically increases throughput, making the improvement better than the arithmetic suggests, for four reasons:

Context switching is not free. Every additional concurrent item costs a developer re-loading mental state. The effective loss compounds — juggling three items costs materially more than three times the switching cost of one.
Feedback arrives sooner. Shorter cycle time means defects are found closer to the moment the code was written, when the author still remembers the design and the fix is cheap. This is the same economic argument behind Test Pyramid and TDD.
Idle capacity redirects to bottlenecks. When the WIP limit blocks someone from starting new work, they go help finish something — swarming a review, pairing on a stuck item — which raises the constraint’s throughput.
Less rework. Long-lived branches diverge from main, producing merge conflicts and integration defects that never existed in the original work. Short cycle time is the precondition for meaningful CI-CD.

Where the Law Bites Back

Little’s Law is exact, but it is exact about averages over a stable system. Three conditions must hold or your numbers lie:

Consistent units. WIP, throughput, and cycle time must be measured over the same boundary. If cycle time is measured from commitment but WIP counts everything on the board including the backlog, the arithmetic is meaningless.
Stability. Arrivals must approximately equal departures over the window. A team whose backlog grows every week is not stable and cannot use the law predictively.
Nothing vanishes. Items abandoned mid-flight, silently split into three, or merged into another leave the system without departing through the delivery point, corrupting both throughput and cycle time.

And it says nothing about variability. Two teams with identical 5-day average cycle time can have wildly different 85th percentiles — one delivers everything in 4–6 days, the other in 1–20. Forecast with percentiles from your actual distribution, never with the mean. “85% of items finish within 9 days” is a usable promise; “the average is 5 days” is not, because roughly half of everything will breach it.

Flow Metrics

Lead Time versus Cycle Time — Measured From Different Points

These are constantly conflated, and the conflation destroys the conversation with stakeholders. Both end at the same place — delivery. They start at different points.

Lead time starts when the customer’s request enters the system (the item is created / accepted into the backlog). It is the customer’s experience of waiting. It includes all the time the item sat in a backlog before anyone touched it.
Cycle time starts at the commitment point — the moment the team commits to finishing the item and pulls it into active work. It is the team’s execution window.

The gap between them is queue time before commitment, and it is often the largest single component. A team with a 4-day cycle time and a 60-day lead time does not have an execution problem; it has an intake problem. Improving developer productivity there is optimising the wrong 6% of the timeline — the fix is in Product Backlog and Refinement and Prioritization Frameworks, not in the IDE.

Be aware that usage varies. Some literature (and some tools) uses “lead time” for what is described here as cycle time, and the Lean origin of the terms differs from the DORA definition of “lead time for changes” (commit to production). The discipline is to define your start and end points explicitly on the board and use those definitions consistently, not to win a vocabulary argument.

Throughput

Throughput is items completed per unit time. It is deliberately a count, not a sum of estimates — and this is a feature. Counting items sidesteps the entire cost and controversy of Story Points and Estimation. For most teams, item size distribution is stable enough that a count of items forecasts as well as a sum of points, at a fraction of the effort. Teams that split work to a roughly consistent size get this almost free.

Throughput drives probabilistic forecasting. Take the last 10–12 weeks of weekly throughput, sample from it randomly ten thousand times to simulate the next N weeks (a Monte Carlo simulation), and you get a distribution: “we will finish these 40 items in 6 weeks with 85% confidence.” This is far more honest — and empirically more accurate — than a Velocity and Burndown Charts extrapolation, because it propagates your actual variability instead of averaging it away.

The Cumulative Flow Diagram

The CFD is Kanban’s signature chart. The x-axis is time; the y-axis is a cumulative count of items. Each workflow state gets a band, stacked, plotted daily. Every flow metric is readable off it geometrically:

Feature of the CFD	What it measures	Reading
Vertical distance between top and bottom lines	WIP	Total items in the system
Vertical thickness of one band	WIP in that state	Where work is piling up
Horizontal distance between two lines	Approximate cycle time	How long items take
Slope of the top line	Arrival rate	How fast work enters
Slope of the bottom line	Throughput	How fast work leaves

Reading it diagnostically:

A band that widens steadily is a bottleneck. Work is arriving faster than that state clears it. Widening In Review is the most common finding in software teams by a wide margin.
Bands parallel and evenly spaced is a healthy, stable system — arrival rate matches throughput.
A flat bottom line means nothing was delivered in that period, regardless of how busy everyone was.
The top line pulling away from the bottom means WIP is growing without bound — the system is unstable and Little’s Law no longer forecasts.
A band that goes to zero and stays there usually means a column nobody actually uses; simplify the board.

Two supporting charts complete the set. The cycle time scatterplot puts one dot per completed item (x = completion date, y = cycle time) with percentile lines drawn across — it exposes outliers and variability that the CFD averages away. The aging work-in-progress chart plots currently-unfinished items by column against those same percentile lines, turning the standup into a triage of what is at risk right now.

Why It Matters

It makes WIP visible, and WIP is the hidden variable. Most teams have no idea how many things they have started. The number is almost always two to four times what anyone would guess, and it explains the cycle time they complain about.
It gives a mathematical, not moral, argument for focus. “Stop starting, start finishing” is a slogan; Little’s Law is a theorem. The second one survives contact with a skeptical stakeholder.
It surfaces bottlenecks automatically. A push system hides its constraint behind everyone being busy. A pull system stalls precisely at the constraint, naming it without needing analysis.
It requires no reorganisation to adopt. Start with your current roles, titles, and process. Nothing needs renaming, no one gets a new job description, and there is no adoption cliff — which is why it succeeds where framework rollouts stall on political resistance.
It forecasts probabilistically from real data. Percentile-based service level expectations (“85% within 9 days”) are both more honest and more useful than a single-number date.
It handles unplanned work natively. Interrupt-driven work has no natural iteration boundary. Kanban was designed for continuous arrival and does not need to pretend that demand comes in two-week batches.
It shortens feedback loops as a side effect. Halving cycle time halves the delay before a user reacts to a change — the core mechanism behind continuous delivery and Feature Flags-driven experimentation.
It exposes queue time as the dominant cost. Once queues are visible, the discovery that items spend most of their life waiting reframes improvement away from “type faster” toward “remove handoffs.”
It scales downward gracefully. It works for a team of two, for a solo maintainer, and for personal work. Most frameworks have a minimum viable team size; Kanban does not.

Kanban Is a Method, Not a Framework

This distinction is load-bearing and routinely missed.

Scrum is a framework: it defines roles (Product Owner, Scrum Master, Developers), events (Sprint, Planning, Daily, Review, Retrospective), and artifacts (Product Backlog, Sprint Backlog, Increment). Adopting Scrum means replacing your process with Scrum’s process. It is prescriptive by design — the constraints are the value.

Kanban is a change-management method. Its founding principles are explicit about this:

Start with what you do now — do not change roles, titles, or process at the outset.
Agree to pursue improvement through evolutionary change.
Encourage acts of leadership at every level.
Respect current roles, responsibilities, and job titles.

You do not “switch to Kanban.” You apply Kanban to whatever you are already doing, then let the data drive incremental change. Kanban on a waterfall process is legitimate and produces real improvement. Kanban on Scrum is legitimate — that combination is exactly what “Scrumban” names.

This is why the two compose so naturally, and why Scrumban is one of the most common working arrangements in industry. Teams typically keep Scrum’s cadence and roles while borrowing Kanban’s mechanics:

Kept from Scrum	Borrowed from Kanban
Sprint Retrospective and cross-functional team	WIP limits per board column
Regular planning / replenishment cadence	Cycle time and throughput instead of velocity
Product Owner role and backlog ownership	Continuous delivery within the sprint
A shared stakeholder demo	Explicit column policies and an expedite lane

The migration path is usually the same: a Scrum team adds WIP limits, notices sprint boundaries no longer control anything meaningful because work ships continuously, drops the sprint commitment while keeping the planning meeting as replenishment, replaces velocity with throughput, and one day realises they have been doing Kanban for months. That is the method working as designed — evolutionary change, no adoption event.

The corollary is a warning. Because Kanban prescribes nothing, it provides no scaffolding for teams that lack basic discipline. Scrum’s ceremonies force conversations that would otherwise not happen. Give an undisciplined team a Kanban board and you frequently get an unlimited-WIP task tracker with a Lean vocabulary. Kanban demands more maturity than Scrum, not less, precisely because it withholds structure.

Comparison

Dimension	Kanban	Scrum	Extreme Programming (XP)	Scrumban
Nature	Change-management method, layered on existing process	Full framework, replaces process	Framework plus engineering practices	Hybrid
Cadence	Continuous flow; cadences decoupled	Fixed-length sprint (1–4 weeks)	Short iterations (1–2 weeks)	Planning cadence, continuous delivery
Commitment	Per item, at the commitment point	Batch, to a sprint goal	Per iteration	Per item, planned in batches
Roles	None prescribed; keeps existing	PO, SM, Developers	Coach, Customer, Programmers	Existing Scrum roles
WIP handling	Explicit numeric limits per column	Implicit, via sprint backlog size	Implicit, via pairing	Explicit limits
Primary metrics	Cycle time, throughput, WIP, aging	Velocity, burndown	Velocity, defect rate	Cycle time, throughput
Estimation	Optional; often abandoned for item counts	Story points, mandatory in practice	Points or ideal days	Usually right-sizing only
Change mid-cycle	Anytime, subject to WIP limits	Discouraged during sprint	Discouraged during iteration	Anytime
Board reset	Never; persistent	Typically cleared each sprint	Per iteration	Persistent
Best fit	Interrupt-driven, ops, support, maintenance, mature teams	New product work, teams needing structure	Teams with heavy technical practices	Product teams outgrowing sprint boundaries

A separate axis of confusion is Kanban versus Lean Software Development. Lean is the body of principles — eliminate waste, amplify learning, decide late, deliver fast, build quality in. Kanban is one concrete practice for realising those principles in a workflow. Lean is the why; Kanban is a how.

Why Kanban Fits Interrupt-Driven Work

Sprint-based cadence rests on an assumption: that you can commit to a set of work for two weeks and mostly deliver it. For an ops, support, SRE, or maintenance team, that assumption is simply false, and forcing it produces predictable dysfunction.

Demand arrives stochastically. A production incident does not wait for the sprint boundary. The team cannot know on Monday what Wednesday’s page will be about. A sprint commitment made under that uncertainty is either padded to meaninglessness or broken weekly.

Sprint commitments become theatre. When 40% of a sprint’s capacity is consumed by unplanned work, the sprint goal fails routinely. The team either learns that commitments do not matter — corroding the concept for genuinely committable work — or defensively under-commits, wasting the capacity that unplanned work did not claim.

Batch delivery is wrong for support. A ticket fixed on day 2 delivers value on day 2. Holding it until a sprint review because “we demo at the end” is pure inventory cost with no offsetting benefit.

The wrong metrics get optimised. Velocity is meaningless when work is unestimated interrupts. Cycle time percentiles per class of service — “urgent tickets resolved within 4 hours at the 90th percentile” — map directly onto how support work is actually judged.

Kanban answers this with classes of service: distinct policies for distinct work types, each with its own lane and often its own WIP limit.

Class	Policy	Typical WIP cap
Expedite	Pull immediately, breaks WIP limits, swarm until done	1 board-wide
Fixed date	Scheduled by deadline; started at the latest responsible moment	1–2
Standard	FIFO from the ready queue; the default	Most of the limit
Intangible	Refactoring, tooling, tech debt; pulled when capacity allows	1

Note the Expedite rule: exactly one, board-wide, and it is allowed to violate WIP limits — because a rule that is never permitted to break gets broken informally and invisibly instead. Making the exception explicit and capped at one is what keeps it from becoming the norm. That intangible lane, meanwhile, is how Code Refactoring and Technical Debt gets funded in a system with no sprint planning to allocate it.

Feature-development teams building something new, in contrast, often benefit genuinely from a Sprint boundary: it creates a forcing function for stakeholder demos, a natural rhythm for Sprint Retrospective, and a psychologically useful sense of completion. The right answer is not universal. It depends on whether your demand is plannable.

Real-World Use Cases

Platform and SRE teams run a persistent board with an expedite lane for incidents, a standard lane for platform work, and an intangible lane for toil reduction — with SLEs stated per class (“P1 acknowledged within 15 minutes, resolved 90% within 4 hours”).
Customer support escalation queues use Kanban because ticket arrival is genuinely random; throughput and 85th-percentile resolution time are the metrics leadership already cares about.
Teams practising continuous deployment find sprint boundaries vestigial once changes ship several times a day; the board plus WIP limits is all the coordination the flow requires, backed by CI-CD Best Practices.
Maintenance of legacy systems, where work is bug-driven, unpredictable in size, and impossible to estimate meaningfully — item counts and cycle time percentiles work where story points do not.
Hardware and firmware teams with long, physically-constrained lead times (fab runs, certification) where the queue time between stages dwarfs the active work and only a CFD makes it visible.
Design and content pipelines, where a handful of specialists are a shared constraint across many streams — a WIP limit on the design column prevents the whole organisation from queueing on one person invisibly.
Personal and solo work, including open-source maintenance, where a three-column board with a WIP limit of two is sufficient and any framework would be overhead.
Portfolio and programme boards, where epics rather than stories are the cards, WIP is limited at the initiative level, and the finding is usually that thirty things are “in progress” organisation-wide with four people each.
Data and analytics teams handling a mix of scheduled pipeline work and ad-hoc analysis requests — two classes of service on one board, with the ad-hoc lane WIP-capped to protect the pipeline work.
Scrumban transitions at teams whose sprint commitment has been failing for months: add WIP limits and measure cycle time for six weeks before touching anything else, and the data usually makes the sprint’s removal uncontroversial.

Common Pitfalls

Unlimited WIP. By far the most common failure. A board with columns but no numeric limits is a task tracker, not Kanban. Every mechanism that makes Kanban work — the pull signal, bottleneck visibility, cycle time reduction — derives from the limit. Without it you have redecorated, not changed anything.
Treating the WIP limit as a suggestion. “We’re at the limit but this is important, let’s just add it.” Do that twice and the limit is dead. The value of the constraint is precisely the discomfort it creates; that discomfort is the signal to go finish something or fix the bottleneck.
Modelling the org chart instead of the workflow. Columns named after teams (Backend, Frontend, QA) instead of states (In Development, In Test) turn the board into a handoff map and entrench the silos. Model what happens to the work, not who touches it.
Hiding queues inside active columns. A single In Progress column conceals that items sit idle for days waiting for a reviewer. Split into Doing/Done sub-columns and the waiting time becomes measurable — and usually turns out to be the majority of cycle time.
Skipping explicit policies. Without written entry and exit criteria, cards move on vibes, columns mean different things to different people, and every metric derived from column transitions is noise.
Measuring cycle time from an undefined start. If the commitment point is not marked on the board, cycle time is not reproducible and comparisons across months are meaningless. Draw the line and label it.
Forecasting with averages. The mean cycle time is breached by roughly half of all items. Committing to it guarantees missing half your promises. Use the 85th or 95th percentile from your own distribution.
Cargo-culting the standup. Walking the board left to right, person by person, reproduces a status meeting. Walk it right to left, item by item, oldest first, asking only what each blocked or aging card needs to move.
Ignoring item size variability. Kanban’s item-count metrics assume roughly comparable card sizes. One card that is secretly a quarter-long project wrecks the distribution and every forecast built on it — right-size at the commitment point.
Never revisiting the limits. WIP limits are hypotheses, not settings. If the board never stalls, the limit is too loose to teach you anything; tighten it and observe. If it stalls constantly at one column, you have found your bottleneck — address it rather than relaxing the limit.
Abandoning the retrospective. Because Kanban prescribes no ceremonies, teams frequently drop the improvement loop entirely and stagnate. Practice 6 is not optional; the operations review is where the CFD and cycle time data actually change something.

Example

A payments platform team of six supported a live service while also building new merchant features. Their Jira board had three columns and no limits. On a typical Tuesday it held 27 items marked “In Progress” across six people. Feature work took, by their own reckoning, “somewhere between three weeks and forever.” Stakeholders had stopped asking for dates because the answers had stopped meaning anything.

They changed nothing about roles, titles, or process. They redrew the board to match reality — Ready / Development (Doing, Done) / Review (Doing, Done) / Verify / Deployed — which immediately exposed a Development — Done queue holding nine items waiting on review. They set a total WIP limit of 7, added a single-slot expedite lane for production incidents, wrote the pull policy for each column on an index card taped above it, and started recording each item’s commitment date and delivery date. Then they waited six weeks and drew a cumulative flow diagram. The Review band was a widening wedge: work entered faster than two senior engineers could clear it. Throughput was 9 items per week; WIP had settled around 18; Little’s Law gave a cycle time of about two weeks, matching the measured 85th percentile of 13 days.

The intervention followed from the diagram, not from opinion. They dropped the total WIP limit to 9 and adopted a rule that reviewing beat starting: on finishing an item, you look right before you look left. The math predicted cycle time near one week; six weeks later the measured 85th percentile was 6 days and throughput had drifted up to 11 per week, because reviews now happened while the author still had the context loaded and the rework loop had collapsed. Nobody worked longer hours. Nothing was outsourced. Total output rose slightly while the time each item spent in the system halved — and the team could finally answer the date question honestly: “85% of items like this ship within 6 days of us starting them.” That last sentence, backed by a distribution rather than a guess, was what restored the stakeholder relationship. Twelve weeks in, someone noticed they had not used the word “sprint” in two months.

Referenced by

Dig deeper

Spot an error in this note?