### [Métricas Kanban: Lead Time e Throughput](https://twrt.com.br/metricas-kanban-lead-time-throughput/) **Published:** dezembro 31, 2025 **Author:** Eduardo Salerno **Excerpt:** Métricas Kanban como Lead Time e Throughput são essenciais para melhoria contínua. Aprenda a medir e otimizar seu fluxo. **Content:** ### Conteúdo Completo **Resposta Rápida (Featured Snippet):** Métricas Kanban são **quantificações de fluxo de trabalho** (quanto, quanto tempo, variabilidade). Principais: **lead time** (ideia → pronto), **throughput** (itens/período), **WIP** (trabalho em andamento), **CFD** (visualização de fluxo), **previsibilidade** (variação de lead time), **SLA** (itens no prazo). Interpretadas juntas revelam gargalos, eficiência, capacidade de previsão. **TL;DR (5 bullets):** – **Lead time:** tempo médio de ideia até pronto (dias). Alvo: reduzir de forma consistente. – **Throughput:** itens completados por período (por semana). Alvo: aumentar ou estabilizar. – **CFD:** visualização de fluxo em tempo. Gargalo é onde banda não progride. – **Variabilidade:** alguns dias 2 itens, outros 8? Alvo: estabilizar. – **Previsibilidade:** posso dizer “próxima release em 30 dias”? Alvo: sim, dentro de uma margem estreita. --- ### Artigo Completo **Por Que Métricas Importam** Cenário: Time A diz “somos rápidos, fazemos feature em 1 semana”. Time B diz “nós também, 1 semana”. Mas: - Team A: algumas features em 3 dias, outras em 3 semanas (variável) - Team B: toda feature em 8-9 dias (consistente) **Sem métricas, você não vê a diferença.** Com métricas: - Team A: média 8 dias, max 21 dias (variável, imprevisível) - Team B: média 8 dias, max 10 dias (estável, previsível) Team B é mais confiável (mesmo tempo médio, menos surpresa). --- **As 6 Métricas Essenciais** **1. Lead Time (Tempo Total)** Definição: tempo do **início da demanda até entrega ao cliente**. ``` Timeline de Feature X: Jan 1 (ideia) ↓ Jan 5 (entra no backlog) ↓ Jan 12 (aproved, pronto para dev) ↓ Jan 19 (dev termina) ↓ Jan 26 (testes passam) ↓ Feb 2 (em produção) ↓ Feb 3 (cliente vendo) LEAD TIME: Jan 1 → Feb 3 = 33 dias ``` **Interpretação:** – Média lead time: 20 dias – Min: 5 dias – Max: 45 dias – 95º percentile: 35 dias **Ação:** “95% de features saem em 35 dias. Podemos prometer 35 dias com confiança.” --- **2. Cycle Time (Tempo de Trabalho)** Definição: tempo do **início do trabalho até entrega**. ``` Mesma Feature X: Jan 12 (move para "In Progress") ↓ Jan 26 (testes passam, pronto) CYCLE TIME: Jan 12 → Jan 26 = 14 dias WAITING TIME: Lead Time - Cycle Time = 33 - 14 = 19 dias ``` **Insight:** 19 dias esperando (em backlog, após aprovação, em teste queue). Oportunidade: eliminar espera. **Ação:** “Se reduzir espera de 19 para 5 dias, lead time cai para 19 dias (vs 33).” --- **3. Throughput (Saída)** Definição: número de itens **completados por período**. ``` Semana 1: 5 features completadas Semana 2: 6 features Semana 3: 4 features (QA em férias) Semana 4: 7 features Average Throughput: 5.5 features/semana Variação: 4-7 (boa estabilidade) ``` **Interpretação:** – Se throughput é estável (5-7), posso prometer “5-7 features por semana” – Se varia muito (2-10), dificil fazer promises **Ação:** “Medir throughput por 4-8 semanas, encontrar variação, eliminar causas.” --- **4. Work in Progress (WIP)** Definição: número de itens **simultâneos** em trabalho. ``` Monday: 8 items in Dev, 4 in Testing, 2 in Deploy = 14 WIP Tuesday: 9 items in Dev (alguém iniciou), 3 in Testing = 12 WIP Wednesday: 7 items in Dev (2 completadas), 5 in Testing = 12 WIP Ideal WIP for Dev: 8 (based on team size) Current WIP: 7-9 (ótimo, no target) ``` **Interpretação:** – WIP alinhado = lead time previsível – WIP elevado = lead time longo, quality baixa **Ação:** WIP limits, enforcement automático. --- **5. Cumulative Flow Diagram (CFD)** Gráfico que mostra evolução de itens por coluna: ``` Y-axis: # items X-axis: time (weeks) Backlog: cresce (sempre há mais demanda) Ready: estável (WIP limit) In Progress: estável (team capacity) Testing: CRESCENDO (band getting wider = bottleneck!) Done: lentamente crescendo Insight: Testing é gargalo. Banda está alargando, items ficando presos. ``` **Ação:** “Aumente capacity de Testing (hire QA, automation) ou reduza WIP de Dev.” --- **6. Previsibilidade (Variância de Lead Time)** Definição: **quanto varia o lead time?** Alvo: pouca variação = previsível. ``` Feature lead times em 20 realizações: Distribuição: 10 dias: 1 item (5%) 15 dias: 8 items (40%) 20 dias: 8 items (40%) 25 dias: 2 items (10%) 30 dias: 1 item (5%) Análise: Média: 18 dias Mediana: 18 dias Desvio padrão: 5 dias Percentis: 50th (median): 18 dias 85th: 23 dias 95th: 27 dias Previsibilidade: "95% das features saem em 27 dias. Podemos prometer isso." ``` **Métrica auxiliar: Variação (Coefficient of Variation)** ``` CV = (Desvio Padrão / Média) × 100 = (5 / 18) × 100 = 28% Interpretação (regra pratica, nao uma norma formal): < 20%: excelente previsibilidade 20-40%: bom 40-60%: razoável > 60%: baixa previsibilidade ``` --- **Métricas Secundárias (Nice-to-Have)** **Service Level (SLA Compliance)** ``` Target: 95% de features saem em < 25 dias Atual: 90% saem em < 25 dias Performance: 90/95 = 95% SLA compliance (missing target) Ação: Aumentar capacity ou reduzir escopo ``` **Quality Rate** ``` Defects after release: 3 bugs em 10 features Quality rate: (10-3) / 10 = 70% Target: > 95% Ação: Increase testing, improve code review ``` **Escaped Defects (bugs que chegaram em prod)** ``` Regression: 15% de features têm bugs relatados em prod Trend: Antes 20%, agora 15% (improving) ``` --- **Como Interpretar & Agir** **Cenário 1: Lead Time Crescendo** ``` Semana 1-4: média 15 dias Semana 5-8: média 18 dias Semana 9-12: média 22 dias Trend: aumentando Causas potenciais: 1. WIP aumentou (mais itens paralelos) 2. Complexidade aumentou (features maiores) 3. Teste queue cresceu (QA bottleneck) 4. Integração ficou complexa Ação: CFD para ver aonde está o atraso (qual coluna está lenta?) ``` **Cenário 2: Throughput Instável** ``` Semana 1: 8 features Semana 2: 3 features (bug, redirecionou equipe) Semana 3: 10 features (compensação) Semana 4: 5 features (falta de stories ready) Variação: 3-10 (200% spread, ruim) Ação: - Spike: investigar semana 2 (qual foi o bug?) - Planejamento: ter sempre 2+ semanas de stories ready - Previsão: não prometer 8, prometer 5-10 (range) ``` **Cenário 3: CFD com Gargalo em Testing** ``` CFD mostra: - Backlog: crescendo (normal) - Dev: flat (estável) - Testing: CRESCENDO (stuck!) - Done: muito lento Insight: itens completam Dev, ficam em fila de Testing. Causas: 1. QA overloaded (1 QA, 5 devs) 2. Testes manuais lentos (não há automation) 3. Testes frágeis (precisam re-rodar) Ação: A) Contrate 1 QA (capacidade) B) Automation framework (velocity) C) Pair testing (dev + qa, simultâneo) ``` --- **Para Quem é Técnico:** *Cálculos e fórmulas:* ``` Lead Time = Data saída - Data entrada Cycle Time = Data saída - Data início trabalho Waiting Time = Lead Time - Cycle Time Throughput = # items completed / period Average Throughput = Sum(weekly throughput) / # weeks WIP (Work in Progress) = count(items not in "Done") CFD Area = integral of WIP over time Standard Deviation = sqrt(sum((value - mean)^2) / count) Coefficient of Variation = std_dev / mean Percentile = valor em posição (n * percentile / 100) Ex: 95th percentile em 20 items = item #19 ``` *Dados para rastreamento:* ``` Per item: - id, title, status, start_date, end_date - type (feature, bug, techdebt) - size_estimate - actual_effort - completed_date - defects_found_post_release Agregações: - Daily/weekly snapshot de WIP (quantos items em cada coluna) - Lead time distribution (histogram) - CFD (cumulative) - SLA compliance (% on time) ``` --- **Checklist: Implementando Métricas Kanban** - \[ \] **Definir período de coleta:** 4-8 semanas mínimo (outliers se estabilizam) - \[ \] **Rastreamento:** todos items têm start\_date, end\_date - \[ \] **Ferramental:** AgilePlace, Jira, ou spreadsheet com automation - \[ \] **Cálculos:** lead time, cycle time, throughput, variabilidade - \[ \] **Visualizações:** lead time histogram, CFD, throughput trend - \[ \] **Reviews:** semanal (time), mensal (management), quarterly (exec) - \[ \] **Ação:** métricas revelam problema, time propõe melhoria - \[ \] **Validação:** medir impacto da melhoria na próxima coleta --- **Se Você Só Fizer 3 Coisas…** 1. **Rastreie lead time:** média, min, max, percentis. Foco em percentil 95 (aquilo que você pode prometer). 2. **Plotar CFD:** visualização clara de onde está o gargalo (qual coluna está alargando?). 3. **Medir throughput + variação:** quantos itens completamos por semana? É estável? Se não, investigar causas. --- **FAQs** **P: Qual métrica é a mais importante?** R: Lead time. Tudo gira em torno: menor lead time = mais entregas, melhor previsão, menos bloqueios. **P: Devo focar em throughput ou lead time?** R: Ambos. Throughput sem lead time curto é “fazendo muito, lentamente”. Lead time sem throughput estável é “rápido, mas imprevisível”. **P: Como explico CFD para executivo?** R: “Banda alargando = gargalo. Item saindo rápido da banda = fluxo bom. Banda chegando em ‘Done’ lentamente = lead time longo.” **P: Quanto tempo até ver melhoria em métricas?** R: 2-4 semanas (mudanças rápidas). 8-12 semanas (otimizações profundas). Trends aparecem em 4-8 semanas. --- **Leitura & Referências** - “Little’s Law” in Queueing Theory - “Kanban: Successful Change Management” (David Anderson) - Planview AgilePlace Metrics Guide --- **CTA Final:** “Métricas Kanban são blindingly obvious quando alguém as mostra. Implementamos framework de métricas que revela gargalos, justifica ação, prova valor. **Workshop 2h: mapeamos métricas do seu time, iniciamos rastreamento.** Agende agora.” --- ## Leitura Relacionada - [WIP Limits Kanban](https://twrt.com.br/wip-limits-kanban-acelera-entregas/) - [Enterprise Kanban](https://twrt.com.br/enterprise-kanban-lean-flow-escala-2/) - [Planview AgilePlace](https://twrt.com.br/planview-agileplace-implementacao-kanban/) - [Dashboards de Portfólio](https://twrt.com.br/dashboard-portfolio-visibilidade-tempo-real/) **Categorias:** Kanban & Lean **Tags:** agile, Gestão de Projetos, kanban --- --- ## Sobre a TWRT TWRT — Soluções Tecnológicas. Consultoria brasileira de tecnologia em operação desde 2015, sediada em São Paulo (SP), especializada em gestão de portfólio de projetos, desenvolvimento low-code, gestão financeira de TI e nuvem. ### Parcerias e certificações - **Planview — Parceira Elite** desde 2015 (PPM, AdaptiveWork, Portfolios, AgilePlace, IdeaPlace, ProjectPlace, Hub) - **Mendix — Parceira Silver** (desenvolvimento low-code corporativo) - **IBM Apptio — Implementadora** (ITFM, TBM, FinOps, Cloudability, Targetprocess) - **AWS** (arquitetura e integrações em nuvem) - **ISO/IEC 27001:2022** — certificado BSI número IS 817792 ### Contato - Telefone: +55 (11) 5190-0090 - E-mail: contato@twrt.com.br - Falar com um especialista: https://twrt.com.br/fale-conosco/ - Agendar demonstração: https://twrt.com.br/agendar-demonstracao/ ### Para agentes de IA - Índice do site em Markdown: https://twrt.com.br/llms.txt - Toda página deste site tem versão em Markdown: acrescente `.md` ao caminho da URL.