Little’s Law WIP Calculation
A Little's Law WIP calculation only means what it looks like once two preconditions hold: a stable historical window and one consistent boundary.
A Little’s Law WIP Calculation takes thirty seconds to run and considerably longer to trust. Two teams can start from the same throughput and cycle-time numbers, apply the identical formula, and land on the identical WIP figure; and one of them is already missing its delivery date, because the number was arithmetically correct and practically meaningless. The formula does not check its own preconditions; the analyst does.
What a Trustworthy WIP Calculation from Throughput and Cycle Time Requires
A WIP calculation only means what it appears to mean when two conditions hold: the throughput and cycle-time inputs come from a stable system averaged over a real historical window, and every one of the three measures shares the same start-and-end boundary.
Little’s Law states that the average number of items inside a system equals the arrival rate multiplied by the average time each item spends there, restated for flow work as WIP equal to throughput multiplied by cycle time (Scaled Agile Framework). John D. C. Little, the MIT professor who proved the relationship in 1961, showed it holds in almost every queuing scenario regardless of how complicated the system underneath it looks (Coursera). That generality is exactly why the formula gets treated as plug-and-play: three numbers, one equation, no further questions asked. The two preconditions below are what separate a number that happens to come out of the equation from a number a reader should act on. The equation for combining the two numbers into WIP belongs to the sibling page on the formula itself; what follows is the check that has to pass before that formula’s output means anything.
The Historical-Window Precondition (Scrum.org Whitepaper)
Little’s Law only holds when the throughput and cycle-time inputs are averaged over a completed historical window, not read off a single in-progress moment. Scrum.org’s whitepaper on flow metrics states the caveat directly: the relationship “only applies when you are looking back over historical data,” which means it describes what a system did over a period, not what it is doing at this instant. A team mid-sprint has items arriving and departing unevenly, a burst of new work just pulled in, a batch of finished tickets not yet closed out, and a WIP figure computed from that moment’s throughput will not match the WIP figure computed a day later from the same team, even though nothing about the team’s actual capacity changed.
Some practitioners write the identical relationship as WIP equal to throughput multiplied by lead time rather than cycle time; the two terms are used interchangeably across most flow-metrics writing, and the historical-window caveat applies to either framing equally. The practical consequence is that a single day’s throughput count is not a valid input: the window needs enough completed work passing through it that arrivals and departures have had time to balance, typically several cycle times’ worth of history, before the average stabilizes into something worth reporting.
The Consistent-Boundary Requirement (PM Stack Exchange)
WIP, throughput and cycle time only describe one real system when all three share the exact same start event and end event for counting work. A widely cited answer on PM Stack Exchange frames the three measures as locked together “in a unique and consistent way for any system to which it applies”; and the clause worth unpacking is “to which it applies,” because the lock only holds once the system’s boundary is defined without ambiguity (PM Stack Exchange).
GetNave’s retail-queue analogy makes the requirement concrete: WIP is the count of customers inside the store at one time, throughput is the rate of customers passing through the doors, and cycle time is how long each customer spends browsing before checkout. The analogy holds exactly as long as “inside the store” means the same thing for every customer counted: the moment one customer is counted from the parking lot and another from the checkout line, the three numbers stop describing one system and start describing three overlapping, incompatible ones. Work item tracking fails the same way when WIP is counted from a Kanban board’s “In Progress” column while cycle time is measured from ticket creation: the board excludes backlog time that the cycle-time clock includes, and the resulting WIP figure no longer corresponds to any state the team actually experiences. The formula does not check its own preconditions; the analyst does.
Calculating WIP From Throughput and Cycle Time: A Step-by-Step Worked Example
Calculating WIP from throughput and cycle time means multiplying a measured delivery rate by a measured time-in-system, and the fastest way to trust the result is to walk through one factory’s actual numbers rather than manipulate the formula in the abstract.
Worked Example: Throughput and WIP to Cycle Time (Learn Lean Sigma)
Learn Lean Sigma’s bicycle-factory example works the calculation in the order that keeps the number honest: measure throughput first, count WIP directly second, then solve for cycle time last.
Step 1: Measuring Average Throughput From Shipping Logs
Throughput comes from the shipping log, not from a capacity estimate: the analyst pulls a window of completed shipments and divides by the number of days the window covers, which in the worked example returns an average of 10 bicycles shipped per day. That average already satisfies the historical-window precondition from the section above, because it is built from completed departures rather than a snapshot of activity.
The reason this step comes first matters for what follows: throughput anchors the other two numbers. Get the shipping-log window wrong, too short to smooth out day-to-day swings, or spanning a period when a production line was down, and the WIP and cycle-time figures calculated from it inherit the same distortion, however carefully the later steps are executed.
Step 2: Counting WIP Directly on the Floor
WIP gets counted, not estimated: the analyst walks the factory floor and counts exactly 200 bicycles currently in production, from frame welding through to final inspection. Planview’s guidance on measuring batch size and WIP makes the same point about direct observation; WIP is “a snapshot metric that shows how many work items are actively being worked on at any given time,” and teams using visual boards can read it directly from how many cards sit in active lanes rather than inferring it from throughput or capacity assumptions (Planview).
Counting instead of estimating removes a second source of error from the calculation before cycle time is even computed. An estimated WIP figure carries whatever bias the estimator brought to it, optimism about how much is “really” in flight, or a stale count from the last planning meeting, and that bias propagates directly into the cycle-time result the next step produces.
Step 3: Solving Cycle Time = WIP / Throughput
With throughput and WIP both measured rather than assumed, cycle time falls out of the rearranged formula: 200 bicycles in production divided by 10 bicycles shipped per day equals 20 days of average cycle time. That 20-day figure is the number the factory can now use to quote delivery dates, size its WIP limits, or diagnose whether a bottleneck has crept in somewhere between welding and inspection.
The number is only as trustworthy as the two measurements that produced it, which is why the order of the three steps is not arbitrary; throughput and WIP are the observed facts, and cycle time is the inference drawn from them, not a fourth independent measurement to be reconciled against the other two.
Cross-Checking With a Second Worked Example (Wrike) and Jac Hughes’s Method
A second worked example from a different domain shows the same three-step method generalizing across units: Wrike’s example follows a software team that completes 10 items per week with 30 items in progress, producing an average cycle time of three weeks by the identical division.
Wrike’s Software-Team Example
The units change completely, items per week instead of bicycles per day, tickets instead of physical units on a production line, but the arithmetic and the ordering of steps do not: throughput measured first from completed work, WIP counted directly from the board’s active lanes, cycle time solved last. Ten items per week and thirty items in progress divide out to three weeks, a number the team can compare against what a stakeholder actually experiences waiting for a ticket to close.
That the method survives the switch from physical manufacturing to software delivery is the point of cross-checking it against a second source: a formula that only worked for one domain’s specific unit of measure would not be worth generalizing into a page-level calculation method, and Wrike’s example confirms it travels.
Jac Hughes’s Practitioner Method
Jac Hughes’s 2025 practitioner method for deriving a team’s WIP figure walks the same three measures from the opposite direction; starting from a team’s observed cycle time and throughput history and working backward to a defensible WIP limit rather than forward to a cycle-time estimate (Jac Hughes).
Running the calculation in both directions against two independently sourced examples is what turns a single worked example into a cross-checked method: if bicycles-to-cycle-time and cycle-time-to-WIP-limit both resolve using the same three-way relationship, the formula is confirmed as symmetric rather than merely convenient in the one direction it was first demonstrated.
The Three-Way Rearrangement for Whichever Variable Is Missing
Because the relationship is a simple product, any one of the three variables can be solved for once the other two are known; Orbitant’s rearrangement of the identity lays out all three directions explicitly rather than leaving the reader to derive the algebra themselves.
| Missing Variable | Formula | What It Solves For |
|---|---|---|
| WIP | Throughput × Cycle Time | Included only to complete the three-way identity: this direction is the relationship already established above |
| Cycle Time | WIP ÷ Throughput | Average time an item spends in the system |
| Throughput | WIP ÷ Cycle Time | Delivery rate the system sustains |
Which column matters depends entirely on what data a team already has. A team with a shipping log and a floor count needs the middle row; a team that already knows its cycle time from customer complaints and wants to know what throughput it needs to hit a target needs the bottom row. The identity does not privilege any one of the three as the “output”: it privileges whichever two numbers were easiest to measure directly.
Why a Single Average Misleads: Percentiles, Variability and the Clearing-Function Correction
A single average WIP or average cycle time can look identical for two teams that carry very different delivery risk, because the average discards exactly the variability that determines whether any individual item will ship on time.
Mustafin (2026): Testing the Clearing Function Against Real Flow Data
A. Mustafin’s 2026 study in Frontiers in Applied Mathematics and Statistics examines the validity of the “clearing function” that links WIP, throughput and cycle time: the one peer-reviewed academic source the underlying research turned up on this exact relationship, as distinct from the practitioner-blog explanations most calculator pages rely on (Frontiers in Applied Mathematics and Statistics). A clearing function describes how throughput responds as WIP rises: throughput climbs roughly in proportion to WIP while a system has slack, then flattens and eventually falls as congestion sets in, and Mustafin’s contribution is testing whether that curve matches what real flow data actually does rather than assuming the textbook shape holds everywhere.
Kingman’s formula supplies the complementary piece of queueing mathematics: mean waiting time is approximately proportional to utilization divided by one minus utilization, scaled by a term built from the variability of arrivals and service times (Kingman’s Formula, Umbrex). The utilization ratio is what makes the clearing function bend; as a system’s utilization climbs toward its ceiling, that ratio grows without bound, which is the mathematical reason a WIP calculation that looked stable at 70% utilization can become wildly unreliable at 95%, long before the average throughput number shows any sign of trouble.
The Averaging Trap: Same WIP, Different Risk
Two teams can report the identical average WIP and the identical average throughput and still carry very different delivery risk, because neither average says anything about how spread out the underlying cycle times were. A team where every item takes close to 20 days looks the same on paper, in terms of the average, as a team where half the items finish in 5 days and the other half drag on for 35: the second team’s average is 20 days too, but its worst-case item is nearly twice as far out as the first team’s, and a stakeholder who was told “20 days” has no way to know which team they are dealing with.
High variability, blocked items sitting idle for stretches, and a long tail of unusually slow items all produce this pattern: they widen the distribution around the average without necessarily moving the average itself. Krishna Kumar’s 2025 discussion of how flows stabilize on the Polaris Flow Dispatch practitioner blog makes the same observation from the operational side: a flow that looks calm by its averages can still be carrying enough hidden variability that individual delivery dates swing well outside what the average would suggest, and the instability only becomes visible once someone looks past the mean.
Percentile Sizing and Monte Carlo Forecasting as the Correction
Statistical process control offers the direct fix: plot cycle time on a control chart with medians and percentile bands rather than reporting a single mean, and the spread that the average hid becomes visible as a shape on the chart rather than a number that quietly absorbed it. Sizing decisions then move to a percentile-based service level, using the 85th or 95th percentile of observed cycle time rather than the average as the number a WIP limit gets calibrated against, which is a more conservative, defensible target precisely because it accounts for the slow tail the average ignored.
Monte Carlo simulation is the practical extension of the same correction: instead of collapsing a team’s throughput and cycle-time history into one average and one WIP figure, the simulation resamples from the actual historical distribution thousands of times and returns a range of plausible delivery dates rather than a single point estimate. It consumes exactly the same inputs a Little’s Law calculation uses, historical throughput and cycle time, and returns something closer to what a stakeholder actually needs: not “20 days,” but “20 days most likely, with a real chance of stretching to 35.” Little’s Law supplies the average relationship; simulation supplies the variability the average discards.
How Should a Percentile Range Change What Gets Promised to Stakeholders?
Once the percentile bands or the Monte Carlo output are in hand, the remaining work is deciding what to actually say out loud. A single mean invites a single promised date, and that promise breaks the moment an item lands past it; a range framed around the 85th or 95th percentile instead sets an expectation that already has the slow tail priced in, so a late-running item confirms the forecast rather than contradicting it. The practical shift is small but specific: replace “this will take 20 days” with “this will most likely take 20 days, with roughly a one-in-ten chance of running past 35,” and let the WIP limit itself be calibrated against the conservative end of that range rather than the average.
Common WIP-Calculation Errors: What Gets Miscounted and Why the Number Comes Out Wrong
A WIP calculation that comes out wrong almost always traces back to one mismeasured input: the wrong window, a miscount, or an item quietly excluded from the count.
What Doc Norton’s Critique Says Not to Count
Doc Norton’s critique of over-elaborate “future value” calculations draws the line at what belongs in a WIP figure and what does not: an involved projection built on top of the raw numbers is “informative and interesting” but “not particularly useful beyond making the point that doing more at once takes more time,” when the same three raw inputs plugged straight into Little’s Law answer the practical question directly (Doc Norton). The critique is a warning against adding complexity to the calculation that the calculation does not need: a team chasing a more elaborate model when the plain WIP-throughput-cycle-time relationship already answers the question is solving a problem it does not have.
The corollary is what should not be folded into the count: work that has been proposed but not started, capacity held in reserve for future sprints, or items already shipped but not yet formally closed in the tracking tool. Each of these inflates or deflates the WIP figure relative to what is in process, and each produces a cycle-time result that looks precise while describing a system boundary nobody actually agreed on.
Blocked and Stalled Items as the Silent Error
Blocked and stalled items are the most common silent error in a WIP calculation: they still occupy a WIP slot because they have not shipped, but they contribute nothing to throughput while they sit idle, which inflates the calculated cycle time for every other item still moving through the same system. Scott Graffius’s comparison of two sprint outcomes illustrates the mechanism directly: one scenario finishes only two of seven user stories while leaving partial hours logged against the rest, and the other finishes five of the same seven stories outright, with the difference traceable not to total effort but to how much work sat partially done instead of clearing the system (Scott Graffius).
The Siemens Health Services experience report on agile cycle-time and throughput measurement documents the same failure pattern at organizational scale: a team’s reported throughput looked healthy while a meaningful share of open items had quietly stalled, and the calculated cycle time only converged with what customers actually experienced once those blocked items were tracked explicitly rather than folded silently into an otherwise-normal WIP count Siemens Health Services (Agile Alliance). Dropping blocked items from the WIP count entirely, rather than flagging them as blocked, is worse than leaving them in: it hides the exact signal that would have explained why the calculated cycle time and the customer’s lived experience of waiting had drifted apart.
Reading the Cumulative Flow Diagram Against the Calculated Numbers
A cumulative flow diagram gives every one of the three calculated numbers a visual counterpart, which turns “the numbers look wrong” into a specific, checkable disagreement between the chart and the arithmetic rather than a vague suspicion.
The Vertical Gap: Reading WIP From Arrival and Departure Curves
A cumulative flow diagram plots two rising curves over time, cumulative items arrived and cumulative items departed, and the vertical distance between them at any point in time is exactly the WIP at that moment, since it counts everything that has arrived but not yet departed. Reading WIP off the chart this way gives a second, independent check on the floor count from the worked example above: if the vertical gap at today’s date does not match the number counted by walking the floor, one of the two measurements is wrong, and the diagram at least narrows down which one to re-examine first.
This matters because the chart makes drift visible over time in a way a single point-in-time count cannot: a WIP count taken once a week might miss a gap that widened steadily for three weeks before anyone noticed, while the same gap on a cumulative flow diagram is visible as a widening band the moment it starts.
The Slope and Horizontal Gap: Reading Throughput and Cycle Time
Throughput on the same diagram is the slope of the departure curve, how steeply the cumulative-completed line is climbing, and cycle time is the horizontal distance between the two curves, measuring how long it takes an item that arrived at a given point to reach the departure curve. When the slope of the departure curve flattens even as the arrival curve keeps climbing at its usual rate, the widening vertical gap and the stretching horizontal gap are the same underlying event read two different ways: work is arriving faster than it is clearing, and both WIP and cycle time will rise together until either arrivals slow down or departures speed back up.
When a cumulative flow diagram disagrees with what the calculated WIP, throughput or cycle-time numbers claim, the diagram is the more reliable check, because it is built from the same raw arrival and departure events rather than from an average computed over some chosen window: a disagreement between the two almost always means the calculation’s input window or boundary definition needs re-examining, not that Little’s Law has stopped holding.
The more useful reframing this diagnostic work points toward is asking not “how much work is open” but “where the elapsed time actually went”: a question value-stream mapping answers by making queues, handoffs, batching and rework visible as distinct segments of the timeline rather than one undifferentiated cycle-time number. Flow efficiency, the ratio of active working time to total flow time, names the gap a bare WIP calculation cannot show on its own: two items can share an identical calculated cycle time while one spent nearly all of it under active work and the other spent most of it waiting in a queue between handoffs, and only a flow-efficiency figure, or a value-stream map built alongside it, tells the two apart.
WIP Calculators and CONWIP: Tools for Ongoing Tracking Instead of One-Off Calculation
Interactive calculators from FIRGELLI, EngineersUniverse and CALADE compute WIP, throughput or cycle time from the other two in seconds, while CONWIP replaces the one-off calculation with a single ongoing WIP limit for the whole system.
Interactive Calculators (FIRGELLI, EngineersUniverse, CALADE)
Each of the three tools below takes the identical three-variable relationship and wraps it in an interface built for a different framing of the same question.
| Calculator | Worked Example It Ships With | Result |
|---|---|---|
| FIRGELLI | 18 stories at 2 per developer, unchanged team capacity | Average cycle time drops to about 1.6 weeks |
| EngineersUniverse | L = λ × W, queueing-theory notation for WIP, arrival rate and time in system | General-purpose calculation across any stable queue |
| CALADE | 32 WIP items at 1.25 items/day throughput | About 25.6-day cycle time, improving when WIP is cut to 24 items |
FIRGELLI’s calculator is built around its own worked example: limiting WIP to 18 stories, at two stories per developer, while holding team capacity constant, drops the resulting average cycle time to roughly 1.6 weeks: a live demonstration that lowering the WIP input, with throughput held fixed, is what pulls cycle time down, rather than something teams have to take on faith. EngineersUniverse frames the identical relationship in queueing-theory notation, L equal to lambda multiplied by W, which is the same equation under different letters for readers arriving from an operations-research background rather than a software-delivery one.
CALADE’s glossary-embedded tool runs a worked example with 32 items in WIP against a throughput of 1.25 items per day, computing a cycle time of about 25.6 days, and then shows what happens when WIP is deliberately cut to 24 items: the calculator recomputes a shorter cycle time directly, letting a reader see the WIP-reduction effect before touching their own numbers (CALADE). Running a team’s own throughput and WIP numbers through any of the three returns the same figure the manual arithmetic would: the value of the tool is in trying WIP-reduction scenarios quickly, not in producing a different answer than the formula would.
CONWIP as an Ongoing Alternative to Recalculating Per-Stage Limits
A one-off calculator answers a single question well: what is the WIP right now, given today’s throughput and cycle time. CONWIP answers a different, ongoing question, what should the total-system WIP stay at, by fixing one system-wide WIP limit rather than requiring a fresh calculation at every stage of a multi-stage process. The practitioner literature on CONWIP describes it as “directly interpretable through Little’s Law,” because the same relationship that produces a one-off number also justifies the fixed limit: hold WIP constant at the calculated figure, and throughput and cycle time settle into the corresponding stable pair rather than drifting as work mix shifts from stage to stage.
CONWIP earns its place over per-stage WIP limits specifically when work types vary enough that a limit calibrated for one stage’s typical item size stops fitting another stage’s; recalculating a fresh per-stage number every time the mix shifts is exactly the maintenance burden CONWIP removes by controlling the total instead. Reach for a calculator once, to answer today’s question; reach for CONWIP when the same question keeps coming back every week.
How to Start Applying Little’s Law WIP Calculation
The calculation itself takes minutes; deciding whether the number it produces is worth acting on takes a first real run against a team’s own data, not a generic example borrowed from a factory or a software team that is not this one.
Start by running the boundary check before the arithmetic: write down the exact event that starts the clock and the exact event that stops it, for all three measures, and confirm every item counted uses the same pair of events. A first-run checklist should also record which of the three inputs came from a direct count and which came from a computed average, since a WIP figure read off a dashboard nobody has audited carries different confidence than one taken by walking the floor; and that distinction is worth writing down alongside the number itself, not reconstructed later when the figure gets challenged.
Once the boundary holds and a first WIP figure comes out the other side, the next decision is whether the question is a one-off or a recurring one. A single planning conversation that needs one defensible number can stop at the calculator. A team that finds itself recalculating the same figure every sprint, or discovers through a cumulative flow diagram that its WIP has been drifting upward for weeks without anyone deciding it should, has outgrown the one-off calculation and is looking at the CONWIP conversation instead: not because the arithmetic changed, but because the question it is answering did.
Anonymous. Counted, not tracked.
Where is your organisation with this right now?
What is the hardest part where you are?
In a sentence: what are you trying to work out right now?
No names, no company. Anonymous. Counted, not tracked.