Plan with flow metrics, not hope

A forecast built on hope is a promise you cannot keep

Why are estimates so often heard as commitments, and missed anyway? Part of the answer is human: estimating skill varies, work items carry real variability, and the moment a number leaves the room it hardens into a promise. We forecast from how we wish the work would go, not from how it has actually moved. Flow metrics will not remove that pressure, but they let the team reason from evidence instead of optimism.

The flow signals worth watching

A few measurements, read together, tell you how the system is really behaving. None of them require story points or guesswork. They come from how work has actually crossed the board.

Read the lead time histogram, not the average

A single “average lead time” hides more than it reveals. Plot every finished item by how long it took and you get a lead time histogram, and its shape is almost never a tidy bell. Lead time is typically Weibull-distributed with a long right tail, so a few slow outliers drag the mean upward. People do not live by the mean; they understand the median, every other item. Tell a team “every other item finishes in two days or less” and they know what good looks like, and when an item runs past twice that, it is a signal to raise a hand.

• Use the median as the everyday expectation, not the mean, for lead time the median is always the smaller, more honest number.
• Quote ranges as percentiles: “85% of items finish within N days” instead of one figure.
• Watch the tail: a lengthening tail means the delivery rate is falling before the average admits it.

Little’s Law connects throughput, WIP, and lead time

Three numbers move together, and Little’s Law is the relationship between them. For a stable system, average throughput equals average work in progress divided by average lead time. Rearrange it and average lead time equals WIP divided by throughput, so if you want shorter lead times and cannot add throughput, you carry less work at once. It holds when flow is conserved (what enters eventually leaves) and WIP is roughly stable, which is exactly what a WIP-limited board is for.

A worked example: from backlog to a defensible date

Say a release backlog holds about 675 stories, two teams give you roughly 12 people, each comfortably carrying 2 items at once (WIP ≈ 24), and history shows an average lead time near 0.9 weeks per story. Little’s Law turns that into a duration: 675 × (0.9 ÷ 24) ≈ 25 weeks. Flip the question, “can we finish in 18 weeks?”, and the same law tells you the WIP, and therefore the staffing, you would need to get there. The point is not the exact figure; it is that the conversation now runs on observed flow instead of hope.

The cumulative flow diagram is the same law as a picture

The cumulative flow diagram (CFD) is Little’s Law you can see. Each band is a stage of the workflow. The vertical gap between the top and bottom bands on any date is your WIP, the slope of the bands is throughput, and the horizontal distance across the bands approximates lead time. When a band starts widening, work is piling up in front of a stage faster than it leaves, a queue forming in plain sight, long before it shows up as a missed date.

• Vertical gap = work in progress right now.
• Band slope = throughput, or how fast work is completing.
• Horizontal gap = approximate lead time through the system.
• A widening band = a growing queue or bottleneck to investigate now.

Plan a range, then protect it with a buffer

Real delivery is not a straight line, so a single date is the wrong artifact. Throughput tends to follow an S-curve: slow at the start while the team forms and learns, fast through the middle, slow again at the end as integration, testing, and rework pile up. Little’s Law is only reliable for that fast middle leg, so plan the rest deliberately rather than pretending it will not happen.

• The slow first and third legs, natural ebb and flow Little’s Law will not capture.
• Dark matter, work that expands as you understand it better, often 20% and much more for novel work.
• Failure load, defects, rework, and technical debt the system will have to process.

Add a project buffer sized to the real uncertainty, technology, people, domain, organizational maturity, and then manage it in flight by comparing how much of the work is done against how much of the buffer is gone. That relationship is an early-warning system: it surfaces trouble while you can still act, instead of at the deadline.

The forecasting tool does the arithmetic for you

You should not have to export to a spreadsheet to reason about any of this. On Team and above, ScrumDo includes a Little’s Law forecasting tool built into the room’s Shape surface. Filter the cumulative flow diagram and lead time histogram to the work you care about, a release, a class of service, a team, a work type, and it reads throughput, WIP, and lead time straight from the board and turns them into a defensible date range.

• Ask “when will this be done?” and get a range from observed flow, not a wished-for date.
• Ask “what would it take to finish by a date?” and see the WIP and throughput that range would require.
• Filter the CFD and histogram by release, class of service, team, person, or work type to forecast the slice that matters.
• Carry the same numbers straight into sprint and release planning, with the assumptions visible.

Pair the numbers with the story

Flow metrics tell you that work slowed; self-interpreted stories and sensemaking signals tell you why. A lengthening tail or a widening CFD band is a question, not an answer, and the answer usually lives in what people experienced. Used together, they make forecasts realistic and improvements specific instead of generic.