What it is and why it matters
Flow metrics describe how the system behaves, not how hard people work. They answer the questions customers and managers ask: how long will it take, how much will be done by a given date, what is causing the delay. The approach popularized by Daniel Vacanti treats these answers as probability distributions, because that is what they are in knowledge work. An item does not “take 6 days”; it has an 85% chance of being done within 10 days.
Predictability is not hitting the date of every item. It is having a system that behaves steadily enough for forecasts to be useful, with the confidence level stated.
Key concepts
The five basic measures
- Lead time: time between the commitment point and the delivery point. It is the time the customer perceives after the request has been accepted. Some teams measure from the arrival of the request; so always state which point you measure from.
- Cycle time: time between the start and the end of a defined segment of the flow, usually from the moment the team starts the item until it is completed. In many systems the segment matches the lead time segment; in others, it sits inside it.
- Throughput: number of items completed per unit of time, such as 14 items per week. Count items, not estimation points.
- WIP: number of items that have started and not yet finished.
- Work Item Age: time elapsed since the start of an item that is still in progress. It is the measure that lets you act before the delay happens.
Terms vary across authors and tools. On the exam, the question defines the start and end points when it matters.
CFD: the Cumulative Flow Diagram
The CFD shows, day by day, how many items have reached each step. Each step becomes a colored band. Three readings cover most analyses:
- the vertical distance between the arrival line and the departure line, on a given day, is the WIP for that day;
- the horizontal distance between the lines gives an approximation of the average time items spend in that segment;
- the slope of the departure line is the average delivery rate.
A band that widens indicates accumulation in that step, usually in front of a bottleneck. A departure line that stays flat for several days indicates that nothing is being delivered. Practice these readings in the CFD experience.
Percentiles instead of averages
Cycle time distributions in knowledge work tend to have a long right tail: most items finish quickly and a few take a very long time. The average is pulled by those few items and represents none of them. Percentiles communicate better. If the 85th percentile is 12 days, 85% of completed items took 12 days or less. The cycle time scatterplot, with percentile lines, is the most direct tool for seeing this.
SLE: Service Level Expectation
The SLE (Service Level Expectation) is a forecast of how long an item should take, with a range and a probability: “85% of items are done within 12 days”. It comes from historical data, not from a wish. It is not a contract or a guarantee, and it is not a synonym for predictability either. Its most valuable use is daily: an item whose age is approaching the SLE calls for action before it goes past it.
Probabilistic forecasting and Monte Carlo
For questions about many items, such as “when will these 40 items be done?” or “how many items will we deliver in 30 days?”, Monte Carlo simulation uses historical throughput. For each future day, the simulator draws a real daily delivery value from the past and repeats the process thousands of times. The result is a distribution of possible outcomes.
How you read it depends on the question:
- “When?”: choose the date by which 85% of the simulations have finished. Earlier dates are riskier.
- “How many?”: choose the quantity that 85% of the simulations reached or exceeded. Larger quantities are riskier.
The simulation assumes the near future looks like the recent past; big changes in the team or in the type of work call for new samples. Also keep in mind that items split and new ones appear during delivery. Run scenarios in the Monte Carlo simulator or analyze your team’s history in the flow analyzer.
Flow efficiency
Flow efficiency is the share of total time during which someone actively worked on the item:
flow efficiency = active work time ÷ total time × 100
An item that took 20 days and received 3 days of active work had 15% efficiency. Low values are common in knowledge work and show that the biggest gain usually lies in reducing waits, not in making people faster. To measure it, you need visible queues on the board.
Common mistakes
- Promising the average. A large share of items goes past the average, and the average tells you neither how large that share is nor how much risk you are taking.
- Forecasting with estimation points. Throughput in items usually forecasts as well or better, with less effort.
- Measuring lead time without defining the points. Two teams with the same metric may be measuring different things.
- Using the SLE as an individual target. It describes the system; holding people accountable for it encourages hiding items or splitting them artificially.
How this shows up on the exam
You will read scatterplots, CFDs and simulation results. The decisions tested include: which percentile to use when answering a customer, how to interpret a band that widens in the CFD, which date to give based on a Monte Carlo distribution and which item on the board needs attention given its age and the SLE. There are also simple calculation questions, such as flow efficiency and reading WIP from the CFD.
Frequently asked questions
What is the difference between lead time and cycle time?
Lead time generally measures from the commitment point to the delivery point, which is what the customer feels. Cycle time measures a segment defined by the team, usually from the start of work to completion. Since authors use the terms in different ways, the most important thing is to state the start and end points.
Are SLE and SLA the same thing?
No. An SLA is an agreement, often contractual, with consequences when it is not met. The SLE is an expectation based on the system’s own data, used to manage flow and to talk with the customer about risk.
Does Monte Carlo work with little history?
It does, with caution. A few weeks of daily throughput already produce useful forecasts if the system is stable. With little history, prefer conservative percentiles and rerun the simulation every week.
