Most conversations about team performance start with the wrong question. 'How much are we getting done?' is an output question. The question that actually builds trust with customers, reduces anxiety in leadership, and tells you whether your delivery system is healthy is a different one: how long will it take? When do I need to place my request in order to take delivery when I need it?
Lead time is the answer to that question. It is the elapsed time from the moment the request for a piece of work is accepted until the moment it is delivered. Sometimes this is described as ¨from commitment to delivery.¨ That single number, tracked consistently across many work items and plotted as a probability distribution, tells you more about your Kanban system's health than any sprint velocity chart, story point total, or weekly status update ever will.
This guide consolidates everything you need to understand lead time in Kanban: what it is, how to measure it correctly, how to read its distribution, what the patterns mean, and how to use it to make delivery promises you can actually keep. It also explains how lead time connects to two related concepts — cycle time and Little's Law — that complete the picture.
Lead time is not a vanity metric. It is a fitness metric. It is a key performance indicator for customers – a success criteria!
What is lead time in Kanban?
Lead time in Kanban is the elapsed clock time between two events: the moment a request for a piece of work is accepted until the moment it is delivered to the customer or end user.
In David J. Anderson's original formulation of the Kanban Method, lead time begins at the commitment point — the moment the team accepts a request and implicitly promises to deliver it. This is an important nuance. Work that sits in a backlog or intake queue before being formally accepted is not subject to the lead time clock. It is waiting.
There are circumstances where it is appropriate to measure the lead time from when a ticket first enters a kanban system until it is ready to exit the system: for example, a workflow may be internal to a business and all the work that arrives to that service has already been promised to a customer – it is already committed. In these circumstances the work is committed as soon as it enters the system and hence lead time is measured from the first queue until the last; a second circumstance is common in business with a lower level of organizational maturity, or a mismatch between the maturity of the downstream delivery kanban, and upstream discovery and ideation activities. It is common in lower maturity organizations for there to be ambiguity between what a customer believes to be committed and what the delivery organization actually knows to be committed. This happens frequently in organizations where the work is pushed from the outside, usually into a backlog or other queuing buffer, and is then pulled into the delivery workflow when capacity becomes available. In these push-pull environments, common at maturity levels 1 and 2, it is common to develop two metrics: the customer lead time – the time from when the customer placed the request until it was delivered; and the system lead time – the time from when a piece of work was pulled into the kanban system to be processed until it is delivered. These alternatives are not wrong, rather they are adapted to the organizational maturity or circumstances within which the kanban system is deployed. Usptream, uncommitted queues, buffers, of workflows, are common when the kanban system is customer-facing and the organization is maturing beyond level 2. What matters is consistency of understanding: everyone involved should know the meaning of the metric – when the clock starts ticking, when it stops, and why that span of work activities and queues was chosen.
Lead time vs cycle time
These two terms are frequently confused, and the confusion is costly because they measure different things.
Cycle time is the time spent actively working on an item, usually in a single activity or column on the kanban board — from when an individual or team picks it up to when it is done, or ready to pull to the next stage in the workflow. It excludes waiting time and is generally measured locally, and not end-to-end. In lower maturity, team-focused kanban system, or individual kanban boards, where the workflow is typically only a To Do – Doing – Done sequence, then cycle time and lead time are effectively the same or synonymous. The difference between a local cycle time measure and an end-to-end lead time measure becomes important with end-to-end service delivery, of customer-valued requests, in a workflow at maturity level 2 or above.
Lead time is the total elapsed time — from commitment (of the request) to delivery. It includes waiting time, queue time, blocked time, and active work time.
Cycle time tells you how long local individual activities take to complete. Lead time tells you what the customer experiences. For predictability and delivery promises, lead time is the metric that matters. For identifying internal bottlenecks, waste, and potential improvement opportunities, cycle time may be more appropriate. Both belong in a healthy Kanban system. A full comparison is covered in our guide to cycle time vs lead time.
Why lead time matters more than velocity
Velocity — the number of story points or items completed per sprint — is the metric most development teams default to. It is also, as a standalone number, deeply misleading.
Velocity tells you about the past. It counts what has been completed. It may indicate approximately how any items can be expected in the immediate future. It shows the production rate. However, customers do not care for this metric: they care about when their specific request will arrive. A customer in a café like Starbucks does not care how many espresso drinks are made every 10 minutes, rather they care when their order for one specific espresso drink will arrive. Velocity or production rate is a health indicator – it shows that work is happening and things are being produced. It is not a customer success metric. It is not a fitness metric from the organization. Velocity tells you that you have a heartbeat, that you are alive. Lead time tells you whether you are likely to make people happy, whether you can meet customer expectations. A team can have high velocity and still be chronically late on every delivery that matters.
Lead time, by contrast, is a predictability metric. When you track lead time across dozens or hundreds of completed items, you build a probability distribution that lets you answer questions like:
- If we commit to this item today, what is the probability it will be done within two weeks?
- What lead time can we promise at the 85th percentile — meaning we will hit it or beat it 85% of the time?
- Has our delivery system improved or degraded over the last quarter?
These are the questions that build trust. Customers and stakeholders do not care how many story points you burned. They care whether you can tell them when something will be done — and then actually do it.
There is also a deeper reason to prefer lead time. Velocity is a team-internal metric; it requires context to interpret. Lead time is a customer-facing metric. It maps directly to the experience of the person waiting for your work. Focusing on internal metrics is a common attribute of lower maturity organizations. Higher maturity organizations focus on external, customer-facing metrics. Alignment between what you measure and what the customer experiences is one of the foundational ideas of the Kanban Method.
A team with declining velocity but shrinking lead time variance is becoming more reliable. A team with rising velocity but widening lead time spread is becoming less predictable. Velocity does not directly indicate predictability or trustworthiness.
How to measure lead time in practice
Lead time measurement requires two timestamps per work item: a start date and an end date. The end date is usually unambiguous — it is when the item is deployed, shipped, or handed to the customer. The start date is where teams differ.
Choosing your start date
The most common options are:
- Date of commitment: The work item moves into an 'In Progress' or equivalent column. This is the Kanban Method default. It measures the time the system owes the customer.
- Date of creation / request: The work item is first logged in your tracking system. This measures the total customer wait including pre-commitment queue time.
- Date approved / prioritised: The item is formally added to a prioritised backlog. A reasonable middle ground for teams with formal intake processes.
The choice of start date typically correlates with organizational maturity. Date committed is associated with Maturity Level 3 (fit-for-purpose) and above. Teams aspiring to level 3 or above will start the clock at the commitment point. Date approved or prioritized generally correlates with maturity level 2, or upstream, planning organizations operating at maturity level 2 even if the downstream delivery org is operating at maturity level 1 (a collection of disjointed teams). Date of creation, the default, is most strongly associated with maturity levels 0 or 1 – there is no upstream governance or control, no formal expectation setting, and no triage process to reject requests before they are started.
A worked example
Your team runs a Kanban board with four columns: Backlog → In Progress → Review → Done.
A feature request enters Backlog on 1 April. On 8 April, the team pulls it into In Progress (your commitment point). It moves through Review and is delivered on 22 April.
Lead time = 22 April − 8 April = 14 days.
That 14-day figure joins every other completed item in your lead time dataset. Over time, a hundred of these numbers tell you far more than any single one.
Noise in the data : Weekends and holidays
Should the lead time clock include the delays of weekends and holidays? It is a good question. Writing in ¨Agile Project Management with Kanban¨ Eric Brechner, a manager with Microsoft and later xBox, wrote that he always included the weekends and holidays. Why? For two reasons: firstly, customers experience the wait of weekends and holidays; secondly, Microsoft/xBox allowed employees to work weekends if they chose freely to do so. Generally there was always some progress being made on weekends and hence, it was appropriate to always include it. However, the other argument can easily be made, for example, at item with 10 days lead time may include 2 weekends, and had it been started earlier in the week, it would only have taken 8 days not 10. Hence, there is noise in the signal. Excluding this noise, makes the data cleaner and more accurate. However, if you choose to do this then must communicate to your customers that lead time expectations exclude weekends and holidays, only business days. There isn´t a correct answer to whether you should or should not include weekends and holidays in the calculation, simply make a choice and stick with it. Good metrics reporting tools will generally allow you to include or exclude non-working days as a configuration setting.
Tracking lead time at scale
Manual tracking in a spreadsheet is viable for single kanban systems. For larger organizations with an extensive network of interdependent kanban systems, and dependency management challenges, a dedicated flow metrics tool removes the overhead entirely. Kanban+ FlowMetrics automatically captures and plots lead time distributions from your board data, so your team spends time improving delivery rather than counting days.
Reading your lead time distribution
A single lead time figure tells you about one item. A lead time distribution tells you about your system.
When you plot the lead times of your last fifty or hundred completed items as a histogram — frequency on the vertical axis, number of days on the horizontal — you get a picture of how your delivery system actually behaves. Not how you think it behaves. Not how the plan said it would behave. How it actually does.
The shape of a healthy distribution
A well-functioning Kanban system typically produces a right-skewed distribution with a thin tail. This means:
- Most items cluster in a relatively narrow band — say, 5 to 12 days
- A small number of items take longer, creating a tail that extends to the right
- The tail is thin — meaning outliers are relatively rare
The thin tail is the key signal. It tells you that your system has occasional exceptions but not chronic unpredictability. Those exceptions are workable — you can investigate them, understand them, and usually address them.
For a more technical, mathematical description, the distribution is typically distributed resembling a Weibull function, with a shape parameter, kappa (k), in a range between 1.0 and 2.0. In large volume the data should aggregate to Gaussian (a bell curve, that can also be represented with the Weibull function with value of k greater than 2.0). This entire range may also be referred to as super-exponential, where the exponential function is recognized as Weibull with k = 1.0. Super-exponential meaning ¨above k = 1.0¨. All super-exponential functions are thin-tailed.
What the tail is telling you
A fat tail — where the distribution spreads wide to the right and a large proportion of items take significantly longer than the median — is a system in distress. It means work is getting blocked, stuck in queues, deprioritised, or disrupted by WIP limit violations. The items in the fat tail are not outliers; they are a pattern.
For a more technical mathematical explanation, fat tails are sub-exponential, and typically, resemble power law functions. These fat-tailed curves are generically referred to as Pareto distributed, after Vilfredo Pareto who studied the appearance of power laws in natural and sociological phenomena.
A fat-tail is an indication not just that a system is unpredictable, but that an undesirable event, such as a dependency delay, may come with a very significant impact or cost. With a thin-tail, an outlier may be a few days late – a short delay, low cost – but with a fat-tail, an outlier item may be delayed for weeks, months or even years – a long delay, with a very high cost.
The goal is not to eliminate the tail — some variation is inevitable in knowledge work. The goal is to thin it: to reduce the frequency and severity of the outliers until the distribution tightens into a predictable range.
You cannot manage what you cannot see. The lead time distribution makes the invisible visible — it shows you not just how fast you are, but how reliable you are.
Kanban+ automatically plots your lead time distribution as items complete. You can see your system's shape — and whether it is improving — without a spreadsheet. Start your free trial at Kanban+
Little's Law: the equation connecting lead time, WIP, and throughput
Once you are measuring lead time consistently, a deceptively simple equation unlocks a much deeper understanding of your system. It is called Little's Law, and it comes from queuing theory.
In plain English: the average number of items in your system equals your average throughput multiplied by your average lead time.
Written as an equation:
Or rearranged to show lead time directly:
What this means in practice
Little's Law is not just a mathematical curiosity — it is a management tool. It tells you that if you want to reduce lead time, you have exactly two levers:
- Reduce WIP. Fewer items in the system at any one time means each item moves through faster. This is the primary lever the Kanban Method gives you: WIP limits.
- Increase throughput. Complete items faster, whether by improving flow, removing blockers, or improving capability.
We may also view this from the other side: if we can detect and eliminate delays, reducing the lead time, then the throughput will rise dramatically for a fixed WIP. It is for this reason that many early kanban experience reports and case studies such as the implementation at Microsoft XIT Sustaining Engineering in 2005 produced dramatic improvements in throughput (velocity or delivery rate) of 230% or more than 3x without additional cost or resources.
Consider a simple example. A team has an average of 20 items in progress at any given time, and completes an average of 2 items per day. Their average lead time is:
20 ÷ 2 = 10 days
If they reduce WIP to 10 items without changing throughput, lead time drops to 5 days. They did not work harder or hire anyone. They changed how much work they allowed into the system at once.
This is why WIP limits are not an arbitrary rule imposed by Kanban coaches. They are the mechanism that makes Little's Law work in your favour. For a full exploration of how the Kanban Maturity Model describes WIP management at different organisational levels, see the Kanban Maturity Model overview.
Use of and appropriateness of Little´s Law is a deep topic that deserves entire book chapters dedicated to it. Suffice here to state that (1) it is not generally applicable, (2) should be used as a forecasting tool with caution and only when certain conditions apply – the main one being that the equilibrium assumption is valid – that the near future (system conditions) will continue to reflect the recent past (from which the data was sampled), and (3) Little´s Law as stated above is an equation of averages – each parameter in the equation is an average. Consequently, there is an underlying unstated mathematical assumption that the parameters in the equation are Gaussian distributed or super-exponential with a very large sample set aggregating to Gaussian. Flipping this into simple, plain language – Little´s Law is only safe to use with thin-tailed distributions of data. If you have a fat-tailed lead time distribution then Little´s Law should not be used.
Little´s Law will perform fairly well on individual or team-focused kanban boards and workflows – in other words, short workflows without multiple activities, without queuing states, without dependencies and other complexity. At maturity level 2 and above with longer workflows, the focus first should be to thin the tail of the lead time distribution before seeking to use Little´s Law to estimate WIP limits for capacity allocations or forecast batch deliveries.
Common lead time patterns and what they mean
Once you can read a lead time distribution, you will start to recognise patterns that recur across teams and systems. Each pattern is diagnostic — it points to a specific underlying cause and a specific set of remedies.
| Pattern | What it signals — and what to do |
|
Thin-tailed, right-skewed |
This is the target state. Most items complete in a predictable band; occasional outliers exist but do not dominate. Action: maintain WIP limits, continue monitoring for early signs of tail widening. |
|
Fat-tailed, right-skewed |
Chronic unpredictability. Many items are taking much longer than the median. Common causes: WIP limit violations, blocking dependencies, unclear acceptance criteria, or work items that are too large. Action: investigate the oldest items in the system; audit WIP limit compliance. |
|
Bimodal distribution (two humps) |
Two distinct populations of work are being tracked together — often a fast-moving class (bugs, small requests) and a slower class (features, infrastructure). Action: segment your data by service class and analyse each separately. The Kanban Method's classes of service exist precisely for this reason. |
|
Uniform / flat distribution |
No consistent flow management. Work items are arriving, getting stuck, being expedited, and completing in no predictable order. Seen in teams new to Kanban or teams where WIP limits are ignored. Action: establish explicit WIP limits and enforce them consistently for 4–6 weeks before re-examining. |
If your distribution is bimodal, this is worth exploring further. The Kanban Method offers a formal approach to managing different types of work through classes of service — a policy-based framework that lets you apply different WIP limits, prioritisation rules, and lead time targets to different categories of work.
Lead time SLAs and making predictable delivery promises
Understanding your lead time distribution is intellectually satisfying. Using it to make commitments you can keep is where it becomes commercially valuable.
The mechanism is a percentile-based Service Level Agreement (SLA). Rather than promising a fixed delivery date — which assumes you can predict the future — you promise a probability: '85% of items committed to this service class will be delivered within X days.'
How percentile SLAs work
Look at your lead time distribution. Find the value at the 85th percentile — the point below which 85% of your completed items fall. That number is your 85th-percentile SLA.
For example: if 85% of your items complete within 14 days, your SLA is '14 days at 85% confidence.' When you commit to a new item, you can honestly say: there is a 15% chance this takes longer than two weeks, and we will flag it proactively if that looks likely.
This is a fundamentally different conversation with a stakeholder than 'it depends' or 'we'll do our best.' It is evidence-based, it is honest about uncertainty, and it is actionable.
Choosing your percentile
Different contexts call for different percentiles:
- 50th percentile (median): The point at which half of items complete faster, half slower. Too risky for external commitments — it is guaranteed to be wrong half the time.
- 70th–75th percentile: Reasonable for internal team planning and sprint-like cadences where some miss is tolerable.
- 85th percentile: The Kanban+ default and the most common choice for external commitments. Confident without overpromising.
- 95th percentile: For high-stakes, low-tolerance commitments — regulatory work, critical client deliverables. Conservative but defensible.
We like 85% because it is almost exactly 6 out of every 7. In early kanban implementations in the late 2000s, we found that customers were often willing to accept a service level expectation of 6 out of 7 within the promised schedule, or 1 out of 7 being slightly late. Note: the psychology here is strongly affected by a thin-tailed distribution. If you have a fat-tailed distribution where the penalty (the delay) for being an outlier could be weeks, months or even years, then the customer is more likely to demand a higher probability perhaps even as high as the 98th %ile.
The value of Lead Time lies hidden in plain sight in its name, ¨lead¨ time. This expresses the concept of ¨if I know when I might want to take delivery of something, then I want to know when I must order it, such that I can trust that it will be delivered on or before that needed date.¨ We can think of this as ¨The Wedding Cake Problem¨. If you are getting married, and you know the date of the wedding, then you know when you must take delivery of the cake. The question then becomes one of ¨When must I place the order with the bakery in order to guarantee delivery of the cake before the wedding?¨
Hence, lead time distributions exist primarily to inform selection, scheduling, commitment and pull decisions at the front-end of a kanban system. Lead times inform start date! And ultimately start dates are what we control. We have active control over the choice to start something. We do not actively control when something will be finished.
The right percentile is a business decision, not a statistical one. It will reflect whether or not the lead time is fat or thin-tailed. It will reflect the organizational maturity. It will reflect the tolerance for delay and the cost and impact of any delay. Using a lower percentile such as 70% will make lead times look short but 3 in every 10 items will miss the expectation. Is there enough trust to balance this impact? Using a higher percentile such as 98% will make the system look slow and unresponsive – everything will need to be planned so much further in advance. Do the conditions exist to make this possible? A balance has to be struct balancing risk and comfort.
Kanban+ calculates your lead time SLAs automatically by service class and displays them alongside your distribution chart — so you always know what you can promise, and to whom. Start your free 30-day trial at Kanban+
Communicating SLAs to stakeholders
When presenting percentile-based SLAs to non-technical stakeholders, the framing matters. Avoid saying 'there's a 15% chance we miss.' Instead, say:
"Based on our historical delivery data, items like this one typically complete within 14 days. We track all commitments against this target and will let you know proactively if anything looks at risk."
This framing is accurate, confidence-building, and positions your team as data-driven rather than guessing. It also creates a natural opening for a conversation about priority if the stakeholder needs something faster — rather than a conversation about whether you can work harder.
Frequently asked questions
What is the difference between lead time and cycle time in Kanban?
Lead time is the total elapsed time from when a work item is accepted for delivery (committed) until it is delivered. Cycle time is the active working time in any given activity in a workflow. Lead time includes all waiting time and queue time; cycle time does not. For delivery promises to customers, lead time is the correct metric. In some cases, average cycle time is expressed as the inverse of the delivery rate. For example, if we deliver 4 items per hour, we might say that average cycle time is 15 minutes. This definition is particularly common in manufacturing environments but is seldom used with knowledge work and professional services kanban systems.
What is a good lead time for a software development team?
There is no universal answer — it depends entirely on your type of work, team size, and organisational context. A small product team doing web features might target a two-week 85th-percentile SLA. An enterprise software team handling complex integrations might target six weeks. What matters is not the absolute number but whether your distribution is stable, whether your tail is thinning over time, and whether your SLA reflects what you can actually deliver. A good lead time is one you can predict and consistently meet.
How do I reduce lead time in Kanban?
The single most effective lever to reduce lead time is reducing Work in Progress (WIP). The second most effective approach is to defer commitment by pushing the commitment point further into the workflow and not counting lead time during initial queuing, backlog or other waiting stages at the front-end of the workflow. Next, focus on sources of delay: the most common source of delay is queues, so reducing work-in-progress (WIP) will already take care of a lot of delay; other sources of delay include non-instant availability of shared services or specialist workers, dependencies on other systems or specific resources such as shared equipment with limited capacity, waiting for approvals and other decisions from people not instantly available; regular cadences for simpler coordination, for example, a weekly replenishment meeting is simple to coordinate, but involves buffering work for 1 week, effectively creating a queue of WIP. Switching to on-demand replenishment is harder to coordinate but eliminates the queue, reducing WIP in the system, and shrinking lead times accordingly.
What causes a fat-tailed lead time distribution?
A fat tail means too many items are taking much longer than the median, at least 5.6 times longer and often much much longer. This is almost always a system problem, not a people problem. The most common causes are: WIP limit violations (too much concurrent work), unclear or changing requirements causing rework, blocking dependencies on other teams or external parties, and insufficient attention to aging items (items that have been in the system for a long time without completion). Fixing a fat tail requires the owner of the system – the delivery manager – to build the visibility, tracking, data and metrics, to measure lead time and identify delays. Then to have the organizational feedback loops such as service delivery review, risk review and operations review in order to reflect on the data, to learn from it, to formulate hypothesis about causes, and system design and policy changes that may generate improvement. The risk is always in the tail. The greatest learning can come from analysing the history of items in the tail: what delayed them and why?
The bottom line
Lead time is the metric that connects how your service delivery organization works to what your customers experience. It is measurable, improvable, and — when managed through the disciplines of the Kanban Method — a genuine source of competitive advantage.
The teams that build durable reputations for reliable delivery are not the ones that work the hardest. They are the ones that understand their own system well enough to make promises they keep.
That starts with measuring lead time. It continues with understanding its distribution. And it matures into using percentile-based SLAs to have honest, evidence-based conversations with the people who depend on your work.
If you want to see your team's lead time distribution without building a spreadsheet, Kanban+ does it automatically. Start a free 30-day trial and have your first lead time chart within minutes of connecting your board.
