Measuring Kanban Flow Metrics for Continuous Improvement
This skill teaches you how to collect, calculate, and interpret the four core flow metrics in a kanban system so you can diagnose bottlenecks, forecast delivery dates, and drive continuous improvement with data instead of gut feel.
Start by recording timestamps when work items enter and exit each stage of your board. Calculate lead time (request to delivery), cycle time (work start to delivery), and throughput (items delivered per period). Plot these on a cumulative flow diagram to spot bottlenecks, then use the data in regular cadences to adjust WIP limits and workflow policies for faster, more predictable delivery.
Outcome: You produce a dashboard of lead time, cycle time, throughput, and a cumulative flow diagram that your team reviews regularly to make evidence-based decisions about process changes, staffing, and delivery commitments.
Prerequisites
- A working kanban board with clearly defined workflow stages
- Understanding of WIP limits and pull-based flow (see /skills/setting-wip-limits)
- Access to historical work item data with timestamps, or willingness to start collecting them
- Basic comfort with spreadsheets or a kanban tool that tracks dates per column
Overview
Every team using kanban methodology eventually faces the same question: how do we know if we are actually improving? Feelings and anecdotes are unreliable. One week the board looks clean and work seems to fly through. The next week everything stalls and nobody can explain why. Flow metrics replace guesswork with observable data. They give you four complementary lenses on how work moves through your system, where it gets stuck, and whether your changes are making things better or worse.
The four core metrics are lead time, cycle time, throughput, and the cumulative flow diagram (CFD). Lead time measures the total elapsed time from when a customer or stakeholder requests something until it is delivered. Cycle time measures the subset of that duration where the team is actively working on the item. Throughput counts how many items the team completes in a given period, usually per week or per two-week window. The cumulative flow diagram visualizes all of these dynamics on a single stacked area chart, making bottlenecks, queues, and flow interruptions visible at a glance. Together, these metrics form the empirical backbone of the kanban methodology's commitment to evolutionary improvement.
The concrete artifact you produce is a living metrics dashboard, whether that is a spreadsheet, a tool-generated report, or a wall chart. It includes a running scatter plot of lead times, a histogram showing cycle time distribution, a throughput trend line, and a CFD. This dashboard feeds directly into your team's cadences and feedback loops, giving every retrospective, replenishment meeting, and delivery planning session a shared factual foundation. Without it, process improvement conversations devolve into opinion wars. With it, you can point to a widening band on the CFD and say, 'Our review queue is growing, and that is adding two days to lead time. Let's talk about why.'
How It Works
Flow metrics work because they treat your kanban system as a pipeline and apply queuing theory to understand its behavior. The fundamental insight comes from Little's Law: the average number of items in a stable system equals the average throughput multiplied by the average lead time. If you know any two of these values, you can derive the third. More practically, if your team has a WIP limit of 12 items and delivers 6 items per week, the average lead time is 2 weeks. If lead time is climbing but throughput is flat, WIP is accumulating somewhere, and a CFD will show you exactly where.
Lead time and cycle time answer different questions. Lead time captures the customer's experience: how long did I wait? Cycle time captures the team's experience: how long did this take us once we picked it up? The gap between them is wait time, the period an item sits in a backlog or queue before anyone touches it. A large gap signals that your intake process, prioritization cadence, or upstream WIP limit needs attention. A small gap means items move quickly from request to active work, but it does not guarantee fast delivery if cycle time itself is long.
Throughput is the simplest metric, but it is also the most misused. Counting completed items per week tells you the rate of delivery, which is essential for forecasting. However, throughput only means something when the items being counted are roughly comparable in size. If one week you deliver ten small bug fixes and the next week you deliver two large features, the raw throughput numbers are misleading. The fix is not to estimate story points. Instead, right-size your work items so that most of them fall within a similar order of magnitude. When items are consistently decomposed, throughput becomes a reliable forecasting input.
The cumulative flow diagram ties everything together. Each band on the chart represents a workflow stage. The vertical distance between bands at any point in time shows the WIP in that stage. The horizontal distance between the top of the 'Done' band and the top of the 'Requested' band shows the approximate lead time. A healthy CFD has bands that run roughly parallel with a gentle upward slope. Warning signs include bands that widen over time (WIP accumulation), bands that flatten (stalled flow), and sudden staircase jumps in the 'Done' band (batched releases rather than continuous delivery). Reading a CFD is a pattern-recognition skill. You learn to spot the shapes that correspond to specific problems, and each shape points to a different intervention, whether that is lowering a WIP limit, adding a pull policy, or having a conversation with a downstream dependency.
Step-by-Step
Step 1: Define your workflow stages and measurement boundaries
Before you can measure anything, you need explicit agreement on where measurement starts and where it ends. Map your kanban board columns and identify the commitment point (where the team agrees to work on an item) and the delivery point (where the item reaches the customer or stakeholder). Lead time spans from the moment an item enters the system, typically a request column or backlog, to the delivery point. Cycle time spans from the commitment point to the delivery point.
Write these boundaries down and share them with your team so that everyone records timestamps consistently. If your board has sub-columns like 'In Review' or 'Awaiting Deploy,' decide now whether those are separate stages you want to track or part of a larger stage. The more granular your stages, the easier it is to pinpoint bottlenecks later, but also the more data hygiene you need.
Tip: If your board has 'waiting' or 'blocked' sub-columns, track them as separate stages. These queues are often invisible time sinks that only show up when you measure them independently.
Step 2: Instrument your board to capture timestamps
Every work item needs a recorded date for each stage transition. If you use a digital kanban tool, check whether it logs column-change timestamps automatically. Most mature tools do this, but some only record creation and completion dates, which gives you lead time but not cycle time per stage. If your tool does not capture per-column dates, add a custom date field per stage and ask team members to update it when they move a card.
If you use a physical board, designate a rotation role to log transitions on a shared spreadsheet at the end of each day. The key discipline is completeness: a single missing timestamp on a work item means you cannot calculate its cycle time accurately. Establish the habit now rather than trying to backfill weeks later.
Tip: Run a one-week pilot where you audit every card that reaches 'Done' to confirm all timestamps are present. Fix gaps immediately. After one week of clean data, the habit usually sticks.
Step 3: Calculate lead time and cycle time for completed items
Export or collect the timestamps for all items completed in the last 4-8 weeks. For each item, compute lead time as the difference between the delivery date and the date the item entered the system. Compute cycle time as the difference between the delivery date and the commitment point date. Record both values in a spreadsheet or analytics dashboard.
Do not average these numbers yet. Instead, list every item with its individual lead time and cycle time. You want the raw data because averages hide the distribution, and the distribution is where the insight lives. A team with an average cycle time of 5 days might have 80% of items finishing in 2-3 days and 20% taking 15+ days.
Those two populations need different interventions.
Tip: Use calendar days, not business days, unless your organization has a strong reason to exclude weekends. Customers experience calendar days, so lead time should reflect their reality.
Step 4: Visualize cycle time with a scatter plot and percentile lines
Create a scatter plot where the x-axis is the completion date and the y-axis is the cycle time in days. Each dot represents one completed work item. Then overlay percentile lines at the 50th, 85th, and 95th percentiles. The 50th percentile tells you the typical cycle time.
The 85th percentile is a reliable planning target, meaning 85% of items finish at or below this number. The 95th percentile exposes your worst-case outliers. Look at the trend: are the percentile lines rising, falling, or flat? A rising 85th percentile is an early warning that something in your process is degrading.
Dots that sit far above the 95th line are worth investigating individually to understand what caused the delay. ' in a data-backed way.
Tip: When stakeholders ask for a delivery estimate, give them the 85th percentile number, not the average. Say 'Based on our last 30 items, 85% of similar work items finish within X days.' This sets realistic expectations and builds trust.
Step 5: Calculate and chart throughput
Count the number of items your team delivers per week (or per whatever cadence makes sense for your delivery rhythm). Plot this as a simple line chart or bar chart over time. Look for the overall trend, the variability, and any seasonal patterns. A stable throughput with low variability means your system is predictable.
High variability means something is disrupting flow, often external dependencies, context switching, or inconsistent item sizing. ' If it is variable, use a range based on your worst and best recent weeks.
Tip: If throughput swings wildly from week to week, check whether your work items are consistently sized. A week with one giant epic and a week with twelve small tasks will produce misleading throughput numbers. Decompose work to roughly similar sizes for meaningful throughput data.
Step 6: Build a cumulative flow diagram
A CFD is a stacked area chart where each band represents one workflow stage, plotted over time. The y-axis shows the cumulative count of items that have entered each stage, and the x-axis is time (usually days). To build one, take a daily snapshot of how many items are in each stage. Each day adds a row to your dataset.
Stack the stages from bottom (Done) to top (Backlog/Requested). Most kanban tools generate CFDs automatically if you have clean timestamp data. If you are building one manually in a spreadsheet, create columns for each stage and each day, record the running total of items that have entered each stage, then use a stacked area chart. Read the diagram by looking at band widths (WIP in each stage), the horizontal gap between top and bottom bands (approximate lead time), and the slope of the Done band (throughput).
Tip: A healthy CFD has smooth, parallel bands with a steady upward slope. If you see any band widening over time, items are accumulating in that stage faster than they are leaving. That is your bottleneck. Investigate the policies and WIP limits for that stage.
Step 7: Diagnose patterns and identify bottlenecks
With all four metrics in front of you, look for correlated signals. If lead time is rising but cycle time is stable, items are spending more time waiting before work starts, which means your intake or prioritization process is the constraint. If cycle time is rising and the CFD shows a widening band in a specific stage, that stage is the bottleneck, and you should examine its WIP limit, staffing, or upstream quality. If throughput is declining while WIP is constant, items are taking longer to complete, possibly due to increased complexity, technical debt, or external blockers.
Document each pattern you observe along with a hypothesis about its root cause. Bring these hypotheses to your next team retrospective or service delivery review. The goal is not to assign blame but to identify systemic causes that the team can address through policy changes.
Tip: Resist the temptation to act on a single week's data. Look for trends over 4-6 weeks. A one-week spike in cycle time might be a holiday week or an outlier item. A four-week upward trend is a real signal.
Step 8: Set baseline targets and improvement goals
Now that you have data, establish your baseline. Record your current 50th, 85th, and 95th percentile cycle times, your average weekly throughput, and your average lead time. These become your reference point. Then set one specific, measurable improvement goal for the next 4-6 weeks.
' Choose the metric that most directly addresses the pain your team is experiencing. If stakeholders complain about unpredictability, target cycle time variability. If the backlog is growing faster than you can deliver, target throughput. Share the goal with the team and identify one process change, such as adjusting a WIP limit or adding a pull policy, that you believe will move the metric.
Tip: Pick only one metric to improve at a time. Trying to simultaneously reduce cycle time, increase throughput, and lower WIP creates conflicting incentives and makes it impossible to attribute results to any specific change.
Step 9: Review metrics in regular cadences and iterate
Flow metrics are only valuable if they drive action. Integrate your dashboard into your team's existing cadences. In a weekly team sync, spend 5 minutes reviewing the throughput trend and any cycle time outliers. In a biweekly or monthly service delivery review, walk through the CFD and cycle time scatter plot with stakeholders.
In retrospectives, use the metrics to evaluate whether recent process changes had the intended effect. If you lowered a WIP limit two weeks ago, check whether cycle time dropped. If it did not, investigate why. If it did, decide whether to maintain the change or push further.
This creates a continuous improvement loop grounded in evidence rather than opinion. Over time, the team develops an intuitive understanding of its own flow dynamics and can spot problems before metrics even confirm them.
Tip: Post a printed or projected version of the CFD and cycle time scatter plot in a visible location. When metrics are physically present during discussions, teams reference them naturally rather than defaulting to anecdote.
Examples
Example: Small startup product team (5 people, B2C mobile app)
A five-person startup team builds a consumer mobile app. They adopted a kanban board three months ago but have never tracked metrics. The CEO keeps asking when features will ship, and the team keeps missing informal estimates. The board has four columns: Backlog, In Dev, In Review, and Released. They deliver roughly 4-10 items per week with high variability.
The team enables column-change timestamps in their tool and waits two weeks to collect clean data. They export 35 completed items and compute cycle time for each. The scatter plot reveals a bimodal distribution: 60% of items finish in 1-3 days, but 40% take 8-15 days. The 85th percentile cycle time is 12 days.
Drilling into the slow items, they find that 90% of them spent 5+ days in the 'In Review' column because the single senior engineer was the bottleneck reviewer. The CFD confirms a steadily widening 'In Review' band. The team responds by cross-training a second reviewer and lowering the In Review WIP limit from 5 to 2, which forces items to be reviewed before new ones can enter. Four weeks later, the 85th percentile cycle time drops to 6 days and throughput stabilizes at 7-9 items per week.
Example: Enterprise platform team (12 people, B2B SaaS)
A 12-person platform engineering team at a B2B SaaS company delivers infrastructure changes that other product teams depend on. Their board has six columns: Requested, Triaged, In Progress, Code Review, Staging, and Deployed. Lead time is a major pain point because internal customers submit requests and wait weeks with no visibility. The team delivers 3-6 items per week.
The team sets their measurement boundaries: lead time runs from Requested to Deployed, cycle time from Triaged (commitment point) to Deployed. They pull eight weeks of historical data, computing both metrics for 38 completed items. Average lead time is 18 days, but average cycle time is only 7 days. The 11-day gap is pure wait time in the Requested column before triage.
The CFD shows the Requested band growing steadily, confirming that requests arrive faster than the team triages them. Throughput is stable at about 5 items per week. The team implements a weekly replenishment cadence where they triage and commit to new items every Monday, pulling the top-priority items into Triaged up to their WIP limit. They also publish a simple dashboard to internal customers showing current lead time percentiles.
After six weeks, lead time drops to 11 days (the 85th percentile) because the triage wait shrinks from 11 days to 4. Cycle time stays at 7 days. ' messages.
Example: Marketing content team (4 people, agency)
A four-person content marketing team at an agency manages client deliverables on a kanban board. Columns are: Brief Received, Writing, Editing, Client Review, and Published. The team juggles 6-8 clients and struggles with unpredictable delivery. Some articles take 3 days, others take 3 weeks, and neither the team nor clients understand why.
The team starts logging timestamps per column transition in a shared spreadsheet. After three weeks, they have data on 22 completed articles. The cycle time scatter plot shows a clear pattern: articles where the client review stage exceeds 5 days account for nearly all of the outliers above the 85th percentile (14 days). The CFD confirms that Client Review is the widening band.
Throughput is 4-7 articles per week when client reviews come back quickly, but drops to 2-3 when reviews stall. The team cannot control client response time, but they can make it visible. They add a policy: if client review exceeds 3 business days, the item is flagged as blocked and the account manager follows up. They also set a WIP limit of 3 items in Client Review per client.
' Clients who care about speed start prioritizing their reviews.
Example: Large cross-functional product squad (8 people, fintech)
An eight-person product squad at a fintech company includes engineers, a designer, and a product manager. They use kanban methodology with a board that has columns for Discovery, Design, Development, QA, and Release. The squad has been running kanban for six months and already tracks basic throughput, but they have never built a CFD or analyzed percentiles. Stakeholders want more predictable quarterly roadmap commitments.
The squad exports six months of completed item data from their tool, yielding 142 items. They compute cycle time percentiles: 50th at 4 days, 85th at 11 days, 95th at 23 days. The gap between 85th and 95th is alarming, so they investigate the 95th-percentile items. All but two involved a handoff stall between Design and Development, where items sat in a 'Ready for Dev' queue.
Building the CFD confirms this: the Design-to-Development transition band has been slowly widening for months. The squad responds by eliminating the 'Ready for Dev' queue entirely and moving to a pairing model where a developer joins the last day of design to prepare for handoff. They also use throughput data (averaging 6 items per week with a range of 4-8) to forecast quarterly commitments probabilistically. ' After one quarter with the new handoff model, the 95th percentile cycle time drops from 23 to 14 days, and the throughput range tightens to 5-8 items per week.
Best Practices
Measure lead time from the customer's perspective, not the team's. Lead time starts when a request is submitted or a need is identified, not when the team acknowledges it. This distinction matters because reducing internal cycle time while ignoring a three-week backlog wait delivers no improvement from the customer's point of view. If your lead time is three times your cycle time, the biggest gains are in reducing wait time, not speeding up active work.
Use percentiles instead of averages for all time-based metrics. Averages are distorted by outliers and hide bimodal distributions. A team averaging 5-day cycle time might have most items finishing in 2 days with occasional 20-day monsters. Report the 50th, 85th, and 95th percentiles so that planning conversations reflect reality.
Stakeholders can choose their confidence level: the 50th for optimistic estimates, the 85th for commitments.
Maintain a consistent definition of 'done' across all items. If some items are counted as done when code is merged and others when the feature is live in production, your metrics will be inconsistent and your throughput numbers meaningless. Write down your definition of done, post it near the board, and audit it quarterly. Any change to the definition requires a noted break in your historical data.
Right-size work items so throughput data is meaningful. Throughput counts items, not effort. If your items range from 1-hour tasks to 3-week epics, the count tells you very little. Establish a practice of breaking work into items that most of the team can complete in 1-5 days.
When items are roughly similar in size, throughput becomes a powerful forecasting tool. When they are not, throughput is just a vanity number.
Never use flow metrics to evaluate individual performance. The moment you use cycle time or throughput to judge a person, the team will game the metrics. People will cherry-pick small items, avoid difficult work, or stop recording timestamps honestly. Flow metrics measure the system, not the people.
Use them to improve policies, WIP limits, and handoff processes. Individual performance conversations belong in a completely separate context.
Update your metrics dashboard weekly and review it in a standing cadence. A dashboard that is updated monthly and reviewed quarterly is too stale to drive action. Weekly updates let you spot emerging problems within one or two data points. If you skip a week, you lose the habit and data gaps appear.
Assign a rotating owner to ensure the dashboard stays current. The five minutes it takes to update are repaid many times over in meeting quality.
Track and visualize blocked items separately. Items that are blocked by external dependencies, missing requirements, or technical issues distort your cycle time data because they sit in an active stage without progressing. Tag blocked items and filter them when analyzing flow. Then track the frequency and duration of blocks separately.
A high block rate points to systemic issues like poor upstream refinement or unreliable dependencies that no amount of WIP tuning will fix.
Common Mistakes
Using averages as the primary metric and making commitments based on them
Correction
Averages are misleading for flow metrics because cycle time distributions are typically skewed right, with a long tail of outlier items. A team with an average cycle time of 6 days might have a 95th percentile of 22 days, meaning one in twenty items takes almost four times the average. If you commit to 'about 6 days' based on the average, you will miss that commitment 40-50% of the time. Switch to percentile reporting.
Use the 85th percentile for commitments and the 50th for internal planning. Watch for stakeholders who mentally round down to the average anyway, and explicitly label which percentile you are quoting.
Starting measurement before the board's workflow stages are well-defined
Correction
If your board columns are vague or people interpret them differently, your timestamps will be inconsistent. One person moves a card to 'In Progress' when they start thinking about the task, another waits until they write the first line of code. This noise makes cycle time data per stage unreliable. Before turning on metrics, run a brief alignment exercise with the team.
Define what it means for an item to enter and exit each column. Write it down. Use the explicit pull policies skill to formalize these definitions. Then start measuring.
Two weeks of clean data beats two months of noisy data.
Treating the cumulative flow diagram as a status report instead of a diagnostic tool
Correction
Teams often glance at the CFD, note 'we have 8 items in progress,' and move on. That is reading it as a snapshot, which misses the entire point. The CFD's power is in its shapes over time. A widening band signals accumulating WIP.
A flattening Done band signals stalled throughput. Staircase steps in the Done band mean work is being released in batches rather than continuously. Train your team to read the CFD like a doctor reads an EKG, looking for shape changes and trend breaks over the last 2-4 weeks, not just the current state.
Measuring everything from day one and drowning in data
Correction
Some teams instrument every sub-stage, track aging per item, and build elaborate dashboards before they have a single week of clean data. The result is analysis paralysis and dashboard fatigue, where nobody looks at the metrics because there are too many of them. Start with just two metrics: cycle time scatter plot and weekly throughput. Get comfortable reading those and acting on them.
After 4-6 weeks, add the CFD. After another month, add lead time tracking if you have clean intake timestamps. Layer complexity gradually. Each new metric should answer a specific question the team is already asking.
Comparing flow metrics across different teams without context
Correction
A 3-day average cycle time on one team and a 12-day average on another does not mean the first team is four times better. The teams may have different item sizes, different definitions of done, different domains of complexity, or different dependency profiles. Cross-team metric comparisons invite gaming and demoralize slower teams without actually diagnosing anything. Each team should compare against its own historical baseline and its own improvement targets.
If leadership needs a cross-team view, use normalized metrics like the ratio of cycle time to item size, or focus on whether each team is trending in its intended direction.
Ignoring work item aging and only analyzing completed items
Correction
Flow metrics calculated from completed items tell you about the past. They do not warn you about items currently stuck on the board. A card that has been in 'In Review' for 15 days will not show up in your cycle time data until it is done, by which time the damage is done. Add an aging chart or aging WIP report that shows how long each in-progress item has been in its current stage.
Flag any item that exceeds your 85th percentile cycle time while still in progress. This transforms your metrics from a rearview mirror into a windshield.
Other Skills in This Method
Managing Projects with Kanban
How to apply Kanban principles to plan, execute, and deliver projects using pull-based scheduling and continuous delivery instead of fixed sprints.
Running Kanban Cadences and Feedback Loops
How to facilitate the seven Kanban cadences — including standups, replenishment meetings, delivery planning, and service delivery reviews — to enable continuous improvement.
Setting and Enforcing Work-in-Progress Limits
How to determine optimal WIP limits for each workflow stage to reduce bottlenecks, improve flow, and prevent team overload.
Designing Effective Kanban Boards
How to structure columns, swimlanes, and card layouts on a Kanban board to accurately visualize your team's workflow from intake to completion.
Creating Explicit Pull Policies and Workflow Rules
How to define clear entry and exit criteria for each Kanban column so the team knows exactly when and how to pull work forward through the system.
Comparing Kanban and Scrum for Your Team
How to assess the differences between Kanban's continuous flow and Scrum's sprint-based approach to choose or combine the right method for your context.
Choosing the Right Kanban Tools and Software
How to evaluate and select digital Kanban tools like Trello, Jira, and Asana based on team size, workflow complexity, and integration needs.
Frequently Asked Questions
How do I measure flow metrics if my kanban tool does not track per-column timestamps?
Use a parallel spreadsheet with one row per work item and one column per board stage. When you move a card, log the date in the corresponding cell. This takes less than 30 seconds per transition. After two weeks, you will have enough data to compute cycle time and build a basic CFD. If the manual overhead becomes unsustainable, it is a strong argument for switching to a tool that tracks timestamps natively. In the meantime, even imperfect manual data is far better than no data at all.
Should I measure flow metrics before or after setting WIP limits?
Ideally, you do both in parallel. Start collecting data immediately, even if your WIP limits are not yet formal. Your first two to four weeks of metrics will show you where work accumulates, which directly informs where to set or adjust WIP limits. See the [WIP limits skill](/skills/setting-wip-limits) for how to use flow data to choose initial limits. Waiting until WIP limits are perfect before measuring means you have no data to evaluate whether those limits are working.
How long should it take to see results after a process change?
Allow 3-6 weeks of data after a process change before drawing conclusions. Shorter windows are too noisy because weekly throughput and cycle time vary naturally. Longer windows risk confounding results with other changes. If you change a WIP limit on Monday, do not check the metrics on Friday expecting a transformation. Instead, mark the date of the change on your charts and compare the 4-week window before with the 4-week window after. Look for shifts in percentile lines and CFD band widths, not individual data points.
How do I handle items that get blocked by external dependencies in my cycle time calculation?
Tag blocked items and track them in two ways. First, include them in your overall cycle time calculation because they reflect the reality of your delivery system, dependencies and all. Second, calculate a separate 'active cycle time' that excludes blocked days so you can see how long items take when they are actually being worked on. The gap between the two numbers quantifies the cost of external dependencies. Bring this gap to your service delivery review as evidence when advocating for dependency reduction or better cross-team coordination.
Why does my throughput keep fluctuating even though WIP is stable?
Stable WIP with fluctuating throughput usually means item sizes are inconsistent. One week you complete eight small items, the next week you complete two large ones. The WIP count looks the same, but the work content is very different. The fix is not to estimate sizes but to decompose work more consistently. Aim for items that most team members can complete in 1-5 days. Another cause is hidden batch-and-queue patterns where items complete in clusters rather than flowing individually through the system. Check your CFD for staircase patterns in the Done band, which confirm batching.
Can I use flow metrics for forecasting delivery dates on specific features?
Yes, and this is one of the most valuable applications. For a single item, use your cycle time percentiles: 'Based on our data, there is an 85% chance this will be done within X days of starting.' For a set of items, use Monte Carlo simulation: input your historical throughput data, specify how many items need to be delivered, and the simulation will produce a probability distribution of completion dates. Many kanban tools include Monte Carlo forecasting. If yours does not, a simple spreadsheet simulation using random samples from your last 12-16 weeks of throughput data works well.
How do flow metrics relate to the cadences in kanban methodology?
Each [kanban cadence](/skills/running-kanban-cadences) has a natural metrics pairing. The daily standup uses aging WIP to identify items that need attention today. The replenishment meeting uses throughput data to decide how many items to pull into the commitment point. The delivery planning meeting uses lead time percentiles to set expectations with stakeholders. The service delivery review uses the CFD and trend data to evaluate systemic performance. The operations review uses cross-service metrics to optimize the broader value stream. Without metrics, cadences become status meetings. With metrics, they become decision-making sessions.