Kanban em poucas palavras

• Origem: o Kanban nasceu na Toyota, como parte do Sistema Toyota de Produção criado por Taiichi Ohno. No fim dos anos 1940, a Toyota estudou os supermercados, que repõem as prateleiras conforme o consumo; em 1953, aplicou essa lógica na fábrica. A palavra japonesa kanban significa “quadro de sinalização” ou “cartão visual”. ^{[1] [3] [4]}
• Propósito inicial: aumentar a eficiência e reduzir o desperdício. Os primeiros cartões sinalizavam a necessidade de repor estoque: a produção era puxada pela demanda.
• Expansão: o método se espalhou para outros setores. Em 2010, David J. Anderson publicou Kanban, que adaptou a ideia ao trabalho do conhecimento, como software e projetos. ^{[5] [6]}
• Princípios: visualizar o fluxo de trabalho, limitar o trabalho em andamento (WIP), gerenciar o fluxo ativamente e melhorar continuamente.

Hoje o Kanban é uma das abordagens ágeis mais usadas. E, como toda abordagem voltada ao fluxo, depende de métricas para saber se o fluxo está melhorando. O Kanban Guide, de John Coleman e Daniel Vacanti, define quatro medidas de fluxo obrigatórias: WIP, throughput, idade do item (work item age) e tempo de ciclo. As demais métricas deste tutorial complementam essas quatro. ^[2]

O quadro e os pontos de medição

Antes de medir, é preciso combinar onde cada medida começa e termina. O quadro abaixo, baseado no exemplo do texto original, divide o trabalho em duas partes:

• Upstream (descoberta): requisições, backlog e análise. Aqui as ideias ainda são opções; podem ser refinadas ou descartadas.
• Downstream (entrega): do “a fazer” até o “concluído”. Aqui o time já se comprometeu a entregar.

Dois marcos organizam as medidas: o ponto de compromisso, quando o item entra no “a fazer” e o time se compromete com ele, e o ponto de entrega, quando o item fica pronto. Cada equipe pode definir esses pontos de um jeito; o importante é defini-los explicitamente e manter a definição.

WIP e idade do item

Trabalho em andamento (WIP)

WIP = número de itens iniciados e ainda não concluídos

O WIP mostra quantas tarefas estão em andamento ao mesmo tempo. Limitar o WIP é a prática central do Kanban: evita sobrecarga, reduz a troca de contexto e, como mostra a Lei de Little, reduz o tempo de ciclo. No quadro de exemplo, as colunas de andamento aceitam no máximo seis itens; quando o limite é atingido, o time termina algo antes de puxar um item novo. ^[2]

Idade do item (work item age)

Idade do item = data de hoje − data de início do trabalho

O texto original não traz esta métrica, mas ela é uma das quatro medidas obrigatórias do Kanban Guide. Enquanto o tempo de ciclo só existe depois que o item termina, a idade é medida enquanto ele está em andamento. Um item com idade maior que o tempo de ciclo habitual é um sinal precoce de problema: é a hora de agir, antes que ele atrase de vez. ^[2]

Lead time, cycle time e companhia

As métricas de tempo medem trechos diferentes da vida de um item. A figura acompanha um único cartão durante 14 dias.

Lead time

Lead time = data de conclusão − data de compromisso (ou do pedido)

O tempo total que o cliente espera, desde o compromisso até a conclusão. Ajuda a identificar e resolver gargalos. No exemplo, 12 − 2 = 10 dias. ^[11]

Cycle time

Cycle time = data de conclusão − data de início do trabalho

O tempo desde que o item começa a ser trabalhado até ficar pronto. Mede a eficiência do processo e orienta os ajustes. No exemplo, 12 − 4 = 8 dias.

Atenção aos nomes: a literatura não é uniforme. Alguns autores medem o lead time a partir do pedido, e não do compromisso; o Kanban Guide usa um só termo, cycle time, do início ao fim, e deixa cada equipe definir onde fica o início. O que importa é registrar a definição e usá-la sempre igual. ^[2]

Time to market

Time to market = data de lançamento − data de início do projeto (ou da ideia)

O tempo desde a ideia até a entrega ao cliente, incluindo o upstream e a espera pelo lançamento. É a visão do negócio; útil sobretudo em produtos voltados ao cliente. No exemplo, 14 dias.

Tempo bloqueado

Tempo bloqueado = data de desbloqueio − data de bloqueio

Quanto tempo o item ficou parado por um impedimento. Registrar os motivos dos bloqueios revela os problemas recorrentes que atrasam o trabalho. No exemplo, 2 dias.

Throughput

Throughput = total de itens concluídos ÷ período de tempo

Conta quantos itens o time conclui por dia, semana ou mês, e dá uma visão direta da capacidade de entrega. O Kanban Guide recomenda contar itens, não pontos ou horas estimadas. ^{[2] [12]}

Para prever quando um conjunto de itens ficará pronto, é melhor usar a distribuição histórica do throughput, por exemplo numa simulação de Monte Carlo, do que dividir o total pela média. ^[7]

Diagrama de fluxo cumulativo

O texto original termina com um diagrama de fluxo cumulativo (CFD), que reúne várias métricas num só gráfico. Cada faixa mostra quantos itens passaram por uma etapa até cada dia. ^[10]

• Leitura vertical: a espessura de uma faixa num dia é o número de itens naquela etapa, ou seja, o WIP da etapa.
• Leitura horizontal: a distância entre a entrada numa etapa e a saída do fluxo é uma aproximação do tempo de ciclo médio.
• Inclinação: a inclinação da faixa de concluído é o throughput.
• Sinais: faixas que alargam indicam acúmulo; faixas paralelas, fluxo estável; uma faixa plana indica que nada está saindo daquela etapa.

Lei de Little

WIP médio = throughput × tempo de ciclo médio
Tempo de ciclo médio = WIP médio ÷ throughput

Demonstrada por John Little em 1961, a lei relaciona o tamanho da fila, o ritmo de saída e o tempo de permanência num sistema. ^{[8] [9]} Ela explica por que limitar o WIP funciona: com o mesmo throughput, menos itens em andamento significam itens terminando mais rápido.

Um cuidado: a lei vale para médias de longo prazo num sistema estável, em que o que entra é, em média, o que sai, e os itens que começam terminam. Ela explica o comportamento do sistema, mas não serve para prever a data de um item específico; para isso, use os percentis da próxima seção. ^[7]

Previsibilidade com percentis

O tempo de ciclo quase nunca segue uma curva simétrica: a maioria dos itens termina rápido, mas alguns demoram muito, por bloqueios e dependências. Essa cauda longa faz a média enganar. ^[7]

Em vez da média, use percentis: “85% dos itens terminam em até 10 dias” é uma promessa que o time consegue cumprir e o cliente consegue usar. O Kanban Guide chama isso de expectativa de nível de serviço (SLE): o tempo de ciclo esperado para um item, com uma probabilidade. Combinada com a idade do item, a SLE mostra na hora quais itens estão em risco. ^[2]

Eficiência, bloqueios e descarte

Eficiência de fluxo

Eficiência de fluxo (%) = tempo de trabalho ativo ÷ tempo total no processo × 100

• Tempo de trabalho ativo: o tempo em que alguém está de fato trabalhando no item.
• Tempo total: todo o tempo no processo, incluindo esperas e bloqueios.

No cartão do exemplo, foram 3 dias de trabalho ativo num ciclo de 8: eficiência de 37,5%. Os outros 5 dias foram espera e bloqueio. É comum a maior parte do tempo ser espera, e é justamente aí que está a maior oportunidade de melhoria: reduzir filas costuma render mais do que trabalhar mais rápido. ^[15]

Taxa de bloqueio

Itens bloqueados = n
Taxa de bloqueio (%) = itens bloqueados ÷ itens processados × 100

Dependências e bloqueios interrompem o fluxo e introduzem muita variação, o que aparece como a cauda longa no histograma do tempo de ciclo. Acompanhar a taxa, junto com o tempo bloqueado e os motivos, mostra onde atacar.

Taxa de descarte

Itens descartados = n
Taxa de descarte (%) = itens descartados ÷ itens processados × 100

Mede quantas opções são descartadas no upstream, antes do ponto de compromisso. Diferente do que parece, descartar não é ruim: um upstream saudável filtra as ideias fracas cedo, quando é barato, em vez de deixá-las ocupar o downstream.

Qualidade e pessoas

Taxa de defeitos

Taxa de defeitos = número de defeitos ÷ total de unidades entregues

Monitora os defeitos por unidade de trabalho. É essencial para garantir que a velocidade não esteja sendo comprada com qualidade: um throughput alto com muitos defeitos só empurra trabalho para depois.

Satisfação do cliente

Satisfação do cliente = soma das notas de satisfação ÷ número de respondentes

Medida por pesquisas ou retorno direto, mostra se o que é entregue atende ao cliente. Além da média das notas (CSAT), muitas empresas usam o Net Promoter Score (NPS), baseado na pergunta “de 0 a 10, quanto você nos recomendaria?”. ^[16]

Engajamento dos colaboradores

Engajamento = soma das notas de engajamento ÷ número de colaboradores

Avalia o engajamento e o moral do time, que afetam diretamente a produtividade e a qualidade. Pode ser medido por pesquisas periódicas e curtas. ^[17]

Custo do atraso

Custo do atraso (CoD) = valor que se deixa de ganhar por unidade de tempo de atraso
Custo total do atraso = CoD × tempo de atraso
CD3 = CoD ÷ duração do trabalho

O custo do atraso traduz o tempo em dinheiro: quanto se perde a cada semana em que um item não está pronto. Don Reinertsen o chama da “única coisa” que vale a pena quantificar no desenvolvimento de produtos. ^{[13] [14]}

O texto original apresenta o custo do atraso como “valor do trabalho não realizado ÷ tempo de atraso”; a forma mais usada é a acima, em que o CoD já é uma taxa por unidade de tempo e o custo total é essa taxa multiplicada pelo atraso. Para priorizar, divide-se o CoD pela duração (CD3): o item B, pequeno e valioso, vem antes do item C, que vale mais por semana, mas ocupa o time por muito mais tempo. Essa é a lógica do WSJF (weighted shortest job first). ^[14]

Resumo das métricas

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “Kanban em Métricas”, GitHub, texto original deste tutorial, github.com/GiovaniPM/MyCourses/blob/master/Kanban/Metricas.md.
2. John Coleman e Daniel Vacanti, The Kanban Guide, Kanban Guides, acesso em 25/09/2026, kanbanguides.org/english.
3. Wikipedia (em inglês), “Kanban”, acesso em 25/09/2026, en.wikipedia.org/wiki/Kanban.
4. Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988.
5. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010.
6. Wikipedia (em inglês), “Kanban (development)”, acesso em 25/09/2026, en.wikipedia.org/wiki/Kanban_(development).
7. Daniel S. Vacanti, Actionable Agile Metrics for Predictability, 2015.
8. John D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research, v. 9, n. 3, 1961.
9. Wikipedia (em inglês), “Little’s law”, acesso em 25/09/2026, en.wikipedia.org/wiki/Little’s_law.
10. Wikipedia (em inglês), “Cumulative flow diagram”, acesso em 25/09/2026, en.wikipedia.org/wiki/Cumulative_flow_diagram.
11. Wikipedia (em inglês), “Lead time”, acesso em 25/09/2026, en.wikipedia.org/wiki/Lead_time.
12. Wikipedia (em inglês), “Throughput (business)”, acesso em 25/09/2026, en.wikipedia.org/wiki/Throughput_(business).
13. Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas Publishing, 2009.
14. Wikipedia (em inglês), “Cost of delay”, acesso em 25/09/2026, en.wikipedia.org/wiki/Cost_of_delay.
15. Niklas Modig e Pär Åhlström, This Is Lean: Resolving the Efficiency Paradox, Rheologica, 2012.
16. Wikipedia (em inglês), “Net promoter score”, acesso em 25/09/2026, en.wikipedia.org/wiki/Net_promoter_score.
17. Wikipedia (em inglês), “Employee engagement”, acesso em 25/09/2026, en.wikipedia.org/wiki/Employee_engagement.

Kanban in a nutshell

• Origin: Kanban was born at Toyota, as part of the Toyota Production System created by Taiichi Ohno. In the late 1940s, Toyota studied supermarkets, which restock shelves according to consumption; in 1953, it applied that logic to the factory. The Japanese word kanban means “signboard” or “visual card”. ^{[1] [3] [4]}
• Initial purpose: to increase efficiency and reduce waste. The first cards signaled the need to restock: production was pulled by demand.
• Expansion: the method spread to other industries. In 2010, David J. Anderson published Kanban, which adapted the idea to knowledge work, such as software and projects. ^{[5] [6]}
• Principles: visualize the workflow, limit work in progress (WIP), actively manage flow and improve continuously.

Today Kanban is one of the most widely used agile approaches. And, like any flow-based approach, it depends on metrics to know whether flow is improving. The Kanban Guide, by John Coleman and Daniel Vacanti, defines four mandatory flow measures: WIP, throughput, work item age and cycle time. The other metrics in this tutorial complement those four. ^[2]

The board and its measuring points

Before measuring, you need to agree on where each measure starts and ends. The board below, based on the original text’s example, splits the work into two parts:

• Upstream (discovery): requests, backlog and analysis. Here ideas are still options; they can be refined or discarded.
• Downstream (delivery): from “to do” to “done”. Here the team has committed to deliver.

Two milestones organize the measures: the commitment point, when the item enters “to do” and the team commits to it, and the delivery point, when the item is done. Each team may set these points differently; what matters is to define them explicitly and stick to the definition.

WIP and work item age

Work in progress (WIP)

WIP = number of items started and not yet finished

WIP shows how many tasks are in progress at the same time. Limiting WIP is Kanban’s central practice: it prevents overload, reduces context switching and, as Little’s Law shows, reduces cycle time. On the example board, the in-progress columns accept at most six items; when the limit is reached, the team finishes something before pulling a new item. ^[2]

Work item age

Work item age = today’s date − work start date

The original text does not include this metric, but it is one of the four mandatory measures in the Kanban Guide. Cycle time only exists once an item is finished; age is measured while it is in progress. An item older than the usual cycle time is an early warning: the time to act is now, before it is truly late. ^[2]

Lead time, cycle time and friends

Time metrics measure different stretches of an item’s life. The figure follows a single card over 14 days.

Lead time

Lead time = completion date − commitment (or request) date

The total time the customer waits, from commitment to completion. It helps find and fix bottlenecks. In the example, 12 − 2 = 10 days. ^[11]

Cycle time

Cycle time = completion date − work start date

The time from when work starts on the item until it is done. It measures process efficiency and guides adjustments. In the example, 12 − 4 = 8 days.

Watch the names: the literature is not consistent. Some authors measure lead time from the request rather than the commitment; the Kanban Guide uses a single term, cycle time, from start to finish, and lets each team decide where the start is. What matters is to record the definition and use it consistently. ^[2]

Time to market

Time to market = release date − project (or idea) start date

The time from the idea to delivery to the customer, including upstream and the wait for release. It is the business view; especially useful for customer-facing products. In the example, 14 days.

Blocked time

Blocked time = unblock date − block date

How long the item was stopped by an impediment. Recording the reasons for blocks reveals the recurring problems that delay work. In the example, 2 days.

Throughput

Throughput = total items finished ÷ time period

It counts how many items the team finishes per day, week or month, and gives a direct view of delivery capacity. The Kanban Guide recommends counting items, not estimated points or hours. ^{[2] [12]}

To forecast when a set of items will be done, it is better to use the historical distribution of throughput, for example in a Monte Carlo simulation, than to divide the total by the mean. ^[7]

Cumulative flow diagram

The original text ends with a cumulative flow diagram (CFD), which brings several metrics together in one chart. Each band shows how many items had passed through a stage by each day. ^[10]

• Vertical reading: a band’s thickness on a given day is the number of items in that stage, that is, the stage’s WIP.
• Horizontal reading: the distance between entering a stage and leaving the flow approximates the average cycle time.
• Slope: the slope of the done band is the throughput.
• Signals: widening bands mean work piling up; parallel bands, stable flow; a flat band means nothing is leaving that stage.

Little’s Law

Average WIP = throughput × average cycle time
Average cycle time = average WIP ÷ throughput

Proved by John Little in 1961, the law relates queue size, exit rate and time spent in a system. ^{[8] [9]} It explains why limiting WIP works: with the same throughput, fewer items in progress means items finishing faster.

One caveat: the law holds for long-term averages in a stable system, where what comes in is, on average, what goes out, and items that start get finished. It explains the system’s behavior, but it does not forecast the date of a specific item; for that, use the percentiles in the next section. ^[7]

Predictability with percentiles

Cycle time almost never follows a symmetric curve: most items finish quickly, but some take very long, because of blockers and dependencies. That long tail makes the average misleading. ^[7]

Instead of the average, use percentiles: “85% of items finish within 10 days” is a promise the team can keep and the customer can use. The Kanban Guide calls this the service level expectation (SLE): the expected cycle time for an item, with a probability. Combined with work item age, the SLE shows right away which items are at risk. ^[2]

Efficiency, blockers and discards

Flow efficiency

Flow efficiency (%) = active work time ÷ total time in process × 100

• Active work time: the time someone is actually working on the item.
• Total time: all the time in the process, including waiting and blocks.

In the example card, there were 3 days of active work in an 8-day cycle: an efficiency of 37.5%. The other 5 days were waiting and blocked time. It is common for most of the time to be waiting, and that is exactly where the biggest improvement opportunity lies: reducing queues usually pays off more than working faster. ^[15]

Blocker rate

Blocked items = n
Blocker rate (%) = blocked items ÷ items processed × 100

Dependencies and blockers stop the flow and introduce a lot of variation, which shows up as the long tail in the cycle time histogram. Tracking the rate, together with blocked time and the reasons, shows where to act.

Discard rate

Discarded items = n
Discard rate (%) = discarded items ÷ items processed × 100

It measures how many options are discarded upstream, before the commitment point. Contrary to appearances, discarding is not bad: a healthy upstream filters out weak ideas early, when it is cheap, instead of letting them take up downstream capacity.

Quality and people

Defect rate

Defect rate = number of defects ÷ total units delivered

It tracks defects per unit of work. It is essential to make sure speed is not being bought with quality: high throughput with many defects just pushes work to later.

Customer satisfaction

Customer satisfaction = sum of satisfaction scores ÷ number of respondents

Measured through surveys or direct feedback, it shows whether what is delivered meets customer needs. Besides the average score (CSAT), many companies use the Net Promoter Score (NPS), based on the question “from 0 to 10, how likely are you to recommend us?”. ^[16]

Employee engagement

Engagement = sum of engagement scores ÷ number of employees

It assesses the team’s engagement and morale, which directly affect productivity and quality. It can be measured with short, periodic surveys. ^[17]

Cost of delay

Cost of delay (CoD) = value not earned per unit of delay time
Total delay cost = CoD × delay time
CD3 = CoD ÷ duration of the work

Cost of delay turns time into money: how much is lost each week an item is not done. Don Reinertsen calls it the “one thing” worth quantifying in product development. ^{[13] [14]}

The original text presents cost of delay as “value of unrealized work ÷ delay time”; the more common form is the one above, where CoD is already a rate per unit of time and the total cost is that rate multiplied by the delay. To prioritize, divide CoD by duration (CD3): item B, small and valuable, comes before item C, which is worth more per week but ties up the team for much longer. This is the logic of WSJF (weighted shortest job first). ^[14]

Metrics summary

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “Kanban em Métricas”, GitHub, original text of this tutorial, github.com/GiovaniPM/MyCourses/blob/master/Kanban/Metricas.md.
2. John Coleman and Daniel Vacanti, The Kanban Guide, Kanban Guides, accessed 25 September 2026, kanbanguides.org/english.
3. Wikipedia, “Kanban”, accessed 25 September 2026, en.wikipedia.org/wiki/Kanban.
4. Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988.
5. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010.
6. Wikipedia, “Kanban (development)”, accessed 25 September 2026, en.wikipedia.org/wiki/Kanban_(development).
7. Daniel S. Vacanti, Actionable Agile Metrics for Predictability, 2015.
8. John D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research, vol. 9, no. 3, 1961.
9. Wikipedia, “Little’s law”, accessed 25 September 2026, en.wikipedia.org/wiki/Little’s_law.
10. Wikipedia, “Cumulative flow diagram”, accessed 25 September 2026, en.wikipedia.org/wiki/Cumulative_flow_diagram.
11. Wikipedia, “Lead time”, accessed 25 September 2026, en.wikipedia.org/wiki/Lead_time.
12. Wikipedia, “Throughput (business)”, accessed 25 September 2026, en.wikipedia.org/wiki/Throughput_(business).
13. Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas Publishing, 2009.
14. Wikipedia, “Cost of delay”, accessed 25 September 2026, en.wikipedia.org/wiki/Cost_of_delay.
15. Niklas Modig and Pär Åhlström, This Is Lean: Resolving the Efficiency Paradox, Rheologica, 2012.
16. Wikipedia, “Net promoter score”, accessed 25 September 2026, en.wikipedia.org/wiki/Net_promoter_score.
17. Wikipedia, “Employee engagement”, accessed 25 September 2026, en.wikipedia.org/wiki/Employee_engagement.

Il Kanban in breve

• Origine: il Kanban è nato in Toyota, come parte del Toyota Production System creato da Taiichi Ohno. Alla fine degli anni Quaranta la Toyota studiò i supermercati, che riforniscono gli scaffali in base ai consumi; nel 1953 applicò questa logica in fabbrica. La parola giapponese kanban significa “insegna” o “cartellino visivo”. ^{[1] [3] [4]}
• Scopo iniziale: aumentare l’efficienza e ridurre gli sprechi. I primi cartellini segnalavano la necessità di rifornire le scorte: la produzione era tirata dalla domanda.
• Diffusione: il metodo si è esteso ad altri settori. Nel 2010 David J. Anderson ha pubblicato Kanban, che ha adattato l’idea al lavoro della conoscenza, come software e progetti. ^{[5] [6]}
• Principi: visualizzare il flusso di lavoro, limitare il lavoro in corso (WIP), gestire attivamente il flusso e migliorare di continuo.

Oggi il Kanban è uno degli approcci agili più diffusi. E, come ogni approccio basato sul flusso, dipende dalle metriche per sapere se il flusso migliora. La Kanban Guide, di John Coleman e Daniel Vacanti, definisce quattro misure di flusso obbligatorie: WIP, throughput, età dell’elemento (work item age) e cycle time. Le altre metriche di questo tutorial completano queste quattro. ^[2]

La board e i punti di misura

Prima di misurare bisogna concordare dove inizia e dove finisce ogni misura. La board qui sotto, basata sull’esempio del testo originale, divide il lavoro in due parti:

• Upstream (scoperta): richieste, backlog e analisi. Qui le idee sono ancora opzioni; possono essere affinate o scartate.
• Downstream (consegna): da “da fare” a “fatto”. Qui il team si è già impegnato a consegnare.

Due traguardi organizzano le misure: il punto di impegno, quando l’elemento entra in “da fare” e il team se ne assume l’impegno, e il punto di consegna, quando l’elemento è pronto. Ogni team può fissare questi punti a modo suo; l’importante è definirli in modo esplicito e mantenere la definizione.

WIP ed età dell’elemento

Lavoro in corso (WIP)

WIP = numero di elementi iniziati e non ancora finiti

Il WIP mostra quante attività sono in corso contemporaneamente. Limitare il WIP è la pratica centrale del Kanban: evita il sovraccarico, riduce i cambi di contesto e, come mostra la legge di Little, riduce il cycle time. Nella board di esempio le colonne in corso accettano al massimo sei elementi; raggiunto il limite, il team finisce qualcosa prima di prenderne uno nuovo. ^[2]

Età dell’elemento (work item age)

Età dell’elemento = data di oggi − data di inizio del lavoro

Il testo originale non riporta questa metrica, ma è una delle quattro misure obbligatorie della Kanban Guide. Il cycle time esiste solo quando l’elemento è finito; l’età si misura mentre è in corso. Un elemento più vecchio del cycle time abituale è un segnale precoce: è il momento di agire, prima che sia davvero in ritardo. ^[2]

Lead time, cycle time e dintorni

Le metriche di tempo misurano tratti diversi della vita di un elemento. La figura segue una sola scheda per 14 giorni.

Lead time

Lead time = data di completamento − data di impegno (o della richiesta)

Il tempo totale di attesa del cliente, dall’impegno al completamento. Aiuta a individuare e risolvere i colli di bottiglia. Nell’esempio, 12 − 2 = 10 giorni. ^[11]

Cycle time

Cycle time = data di completamento − data di inizio del lavoro

Il tempo da quando si inizia a lavorare sull’elemento a quando è pronto. Misura l’efficienza del processo e orienta gli aggiustamenti. Nell’esempio, 12 − 4 = 8 giorni.

Attenzione ai nomi: la letteratura non è uniforme. Alcuni autori misurano il lead time dalla richiesta e non dall’impegno; la Kanban Guide usa un solo termine, cycle time, dall’inizio alla fine, e lascia a ogni team decidere dove sta l’inizio. Ciò che conta è registrare la definizione e usarla sempre allo stesso modo. ^[2]

Time to market

Time to market = data di rilascio − data di inizio del progetto (o dell’idea)

Il tempo dall’idea alla consegna al cliente, compreso l’upstream e l’attesa del rilascio. È la visione del business; utile soprattutto per i prodotti rivolti al cliente. Nell’esempio, 14 giorni.

Tempo bloccato

Tempo bloccato = data di sblocco − data di blocco

Quanto tempo l’elemento è rimasto fermo per un impedimento. Registrare i motivi dei blocchi rivela i problemi ricorrenti che rallentano il lavoro. Nell’esempio, 2 giorni.

Throughput

Throughput = totale elementi completati ÷ periodo di tempo

Conta quanti elementi il team completa al giorno, alla settimana o al mese, e dà una visione diretta della capacità di consegna. La Kanban Guide raccomanda di contare gli elementi, non i punti o le ore stimate. ^{[2] [12]}

Per prevedere quando un insieme di elementi sarà pronto è meglio usare la distribuzione storica del throughput, per esempio in una simulazione Monte Carlo, che dividere il totale per la media. ^[7]

Diagramma di flusso cumulativo

Il testo originale si chiude con un diagramma di flusso cumulativo (CFD), che riunisce più metriche in un solo grafico. Ogni fascia mostra quanti elementi sono passati per una fase fino a ogni giorno. ^[10]

• Lettura verticale: lo spessore di una fascia in un giorno è il numero di elementi in quella fase, cioè il WIP della fase.
• Lettura orizzontale: la distanza tra l’ingresso in una fase e l’uscita dal flusso approssima il cycle time medio.
• Pendenza: la pendenza della fascia fatto è il throughput.
• Segnali: fasce che si allargano indicano lavoro accumulato; fasce parallele, flusso stabile; una fascia piatta indica che nulla esce da quella fase.

Legge di Little

WIP medio = throughput × cycle time medio
Cycle time medio = WIP medio ÷ throughput

Dimostrata da John Little nel 1961, la legge mette in relazione la dimensione della coda, il ritmo di uscita e il tempo di permanenza in un sistema. ^{[8] [9]} Spiega perché limitare il WIP funziona: a parità di throughput, meno elementi in corso significano elementi che finiscono prima.

Una cautela: la legge vale per medie di lungo periodo in un sistema stabile, dove ciò che entra è, in media, ciò che esce, e gli elementi iniziati vengono finiti. Spiega il comportamento del sistema, ma non prevede la data di un singolo elemento; per quello si usano i percentili della prossima sezione. ^[7]

Prevedibilità con i percentili

Il cycle time quasi mai segue una curva simmetrica: la maggior parte degli elementi finisce in fretta, ma alcuni richiedono moltissimo, per blocchi e dipendenze. Questa coda lunga rende ingannevole la media. ^[7]

Invece della media, usa i percentili: “l’85% degli elementi finisce entro 10 giorni” è una promessa che il team può mantenere e il cliente può usare. La Kanban Guide la chiama aspettativa di livello di servizio (SLE): il cycle time atteso per un elemento, con una probabilità. Combinata con l’età dell’elemento, la SLE mostra subito quali elementi sono a rischio. ^[2]

Efficienza, blocchi e scarti

Efficienza del flusso

Efficienza del flusso (%) = tempo di lavoro attivo ÷ tempo totale nel processo × 100

• Tempo di lavoro attivo: il tempo in cui qualcuno lavora davvero sull’elemento.
• Tempo totale: tutto il tempo nel processo, attese e blocchi compresi.

Nella scheda di esempio ci sono stati 3 giorni di lavoro attivo su un ciclo di 8: efficienza del 37,5%. Gli altri 5 giorni sono stati attesa e blocco. È normale che la maggior parte del tempo sia attesa, ed è proprio lì la più grande opportunità di miglioramento: ridurre le code di solito rende più che lavorare più in fretta. ^[15]

Tasso di blocco

Elementi bloccati = n
Tasso di blocco (%) = elementi bloccati ÷ elementi elaborati × 100

Dipendenze e blocchi interrompono il flusso e introducono molta variabilità, che si vede come coda lunga nell’istogramma del cycle time. Seguire il tasso, insieme al tempo bloccato e ai motivi, mostra dove intervenire.

Tasso di scarto

Elementi scartati = n
Tasso di scarto (%) = elementi scartati ÷ elementi elaborati × 100

Misura quante opzioni vengono scartate nell’upstream, prima del punto di impegno. Contrariamente alle apparenze, scartare non è un male: un upstream sano filtra presto le idee deboli, quando costa poco, invece di lasciarle occupare il downstream.

Qualità e persone

Tasso di difetti

Tasso di difetti = numero di difetti ÷ totale unità consegnate

Controlla i difetti per unità di lavoro. È essenziale per assicurarsi che la velocità non venga pagata con la qualità: un throughput alto con molti difetti sposta solo il lavoro più avanti.

Soddisfazione del cliente

Soddisfazione del cliente = somma dei punteggi di soddisfazione ÷ numero di rispondenti

Misurata con sondaggi o feedback diretti, mostra se ciò che viene consegnato soddisfa il cliente. Oltre alla media dei punteggi (CSAT), molte aziende usano il Net Promoter Score (NPS), basato sulla domanda “da 0 a 10, quanto ci raccomanderesti?”. ^[16]

Coinvolgimento dei collaboratori

Coinvolgimento = somma dei punteggi di coinvolgimento ÷ numero di collaboratori

Valuta il coinvolgimento e il morale del team, che influiscono direttamente su produttività e qualità. Si può misurare con sondaggi brevi e periodici. ^[17]

Costo del ritardo

Costo del ritardo (CoD) = valore non guadagnato per unità di tempo di ritardo
Costo totale del ritardo = CoD × tempo di ritardo
CD3 = CoD ÷ durata del lavoro

Il costo del ritardo traduce il tempo in denaro: quanto si perde per ogni settimana in cui un elemento non è pronto. Don Reinertsen lo definisce “l’unica cosa” che valga la pena quantificare nello sviluppo prodotto. ^{[13] [14]}

Il testo originale presenta il costo del ritardo come “valore del lavoro non realizzato ÷ tempo di ritardo”; la forma più usata è quella sopra, in cui il CoD è già un tasso per unità di tempo e il costo totale è quel tasso moltiplicato per il ritardo. Per dare le priorità si divide il CoD per la durata (CD3): l’elemento B, piccolo e prezioso, viene prima dell’elemento C, che vale di più a settimana ma impegna il team molto più a lungo. È la logica del WSJF (weighted shortest job first). ^[14]

Riepilogo delle metriche

Ripasso veloce

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “Kanban em Métricas”, GitHub, testo originale di questo tutorial, github.com/GiovaniPM/MyCourses/blob/master/Kanban/Metricas.md.
2. John Coleman e Daniel Vacanti, The Kanban Guide, Kanban Guides, consultato il 25/09/2026, kanbanguides.org/english.
3. Wikipedia (in inglese), “Kanban”, consultato il 25/09/2026, en.wikipedia.org/wiki/Kanban.
4. Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988.
5. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010.
6. Wikipedia (in inglese), “Kanban (development)”, consultato il 25/09/2026, en.wikipedia.org/wiki/Kanban_(development).
7. Daniel S. Vacanti, Actionable Agile Metrics for Predictability, 2015.
8. John D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research, vol. 9, n. 3, 1961.
9. Wikipedia (in inglese), “Little’s law”, consultato il 25/09/2026, en.wikipedia.org/wiki/Little’s_law.
10. Wikipedia (in inglese), “Cumulative flow diagram”, consultato il 25/09/2026, en.wikipedia.org/wiki/Cumulative_flow_diagram.
11. Wikipedia (in inglese), “Lead time”, consultato il 25/09/2026, en.wikipedia.org/wiki/Lead_time.
12. Wikipedia (in inglese), “Throughput (business)”, consultato il 25/09/2026, en.wikipedia.org/wiki/Throughput_(business).
13. Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas Publishing, 2009.
14. Wikipedia (in inglese), “Cost of delay”, consultato il 25/09/2026, en.wikipedia.org/wiki/Cost_of_delay.
15. Niklas Modig e Pär Åhlström, This Is Lean: Resolving the Efficiency Paradox, Rheologica, 2012.
16. Wikipedia (in inglese), “Net promoter score”, consultato il 25/09/2026, en.wikipedia.org/wiki/Net_promoter_score.
17. Wikipedia (in inglese), “Employee engagement”, consultato il 25/09/2026, en.wikipedia.org/wiki/Employee_engagement.