Postagens

Métricas de fluxo para equipes Scrum: tempo de ciclo, taxa de entrega e o que realmente medir

Sua equipe acompanha a velocidade. Você fala sobre isso no planejamento da sprint, talvez a mencione nas retros. Mas quando um stakeholder pergunta "quando isso estará pronto?" você ainda acaba adivinhando. A velocidade diz quanto você estimou que completou, não quanto tempo as coisas realmente levam ou onde o trabalho fica preso. As métricas de fluxo preenchem essa lacuna. Elas medem o que realmente está acontecendo no seu processo usando dados reais, não estimativas. E você não precisa abandonar o Scrum ou "adotar o Kanban" para usá-las.

As quatro métricas que importam

O Guia Kanban para Equipes Scrum (publicado pela Scrum.org) define quatro métricas de fluxo. Veja o que cada uma delas indica e por que vale a pena acompanhá-las.

Trabalho em progresso (WIP)

A contagem de itens que sua equipe iniciou mas não terminou. Sem fórmulas, apenas um número. O WIP importa por causa de uma verdade simples: quanto mais coisas você faz malabarismo, mais tempo tudo leva. Mudança de contexto, handoffs e tempo de espera aumentam com WIP mais alto. A maioria das equipes se surpreende quando conta pela primeira vez seu WIP real.

Tempo de ciclo

O tempo de calendário decorrido desde quando o trabalho começa até quando está concluído. Não são horas de esforço, é tempo de relógio. O tempo de ciclo é um indicador atrasado. Você só o conhece depois que um item termina. Mas colete pontos de dados suficientes (objetivo de 30+) e você pode dizer coisas como "85% dos nossos itens terminam em 10 dias ou menos." Isso é um Service Level Expectation (SLE), e é muito mais útil do que um palpite baseado em velocidade.

Taxa de entrega

O número de itens que sua equipe finaliza por unidade de tempo, tipicamente por sprint ou por semana. A taxa de entrega é uma contagem de itens completos independentemente do tamanho. Uma história de 3 pontos e uma história de 8 pontos contam como uma cada. Isso parece uma limitação, mas na verdade é uma força: evita todos os debates sobre se seus pontos são "precisos" e mede o que você realmente entregou.

Idade do item de trabalho

O tempo decorrido desde que um item em progresso foi iniciado. Pense nisso como o tempo de ciclo para coisas que ainda não estão prontas. Esta é a única métrica que você deve verificar diariamente. Se a idade de um item está se aproximando do seu tempo de ciclo típico e ainda está longe de estar pronto, isso é um sinal de alerta precoce. Uma vez que o item termina, sua idade se torna seu tempo de ciclo. Até lá, é seu melhor indicador líder.

Como essas métricas se conectam

A Lei de Little conecta as três primeiras: WIP Médio = Taxa de Entrega Média × Tempo de Ciclo Médio Isso importa na prática. Se você reduz o WIP sem mudar mais nada, o tempo de ciclo cai. Sua equipe não precisa trabalhar mais rápido. Ela precisa trabalhar em menos coisas ao mesmo tempo.

Se você quer...	Então...
Reduzir o tempo de ciclo	Diminua seu WIP
Aumentar a taxa de entrega	Finalize o trabalho atual antes de iniciar trabalho novo
Prever datas de entrega	Use percentis de tempo de ciclo (SLEs)
Detectar problemas cedo	Observe a idade do item de trabalho diariamente

Começando sem reformular seu processo

Você não precisa de novas ferramentas ou uma reformulação do processo. Aqui está um caminho prático.

1. Rastreie três datas por item

   Para cada item do backlog do produto, registre quando ele foi criado, quando o trabalho começou e quando foi concluído. A maioria das ferramentas como Jira e Azure DevOps já capturam isso. Você só precisa começar a prestar atenção nisso.

2. Defina seu fluxo de trabalho explicitamente

   Escreva o que "iniciado" e "concluído" significam para sua equipe. Quais são as colunas no seu quadro? Quais são as regras para mover itens entre elas? Esta é sua Definição de Fluxo de Trabalho, e é a base para medição consistente.

3. Colete dados por algumas sprints

   Não tente analisar nada ainda. Apenas deixe os dados acumularem. Você precisa de pelo menos 30 itens completos para padrões significativos, que a maioria das equipes atinge em 3-4 sprints.

4. Crie seu primeiro gráfico de dispersão de tempo de ciclo

   Plote cada item completo com sua data de conclusão no eixo x e tempo de ciclo no eixo y. Desenhe linhas horizontais nos percentis 50, 85 e 95. Seu percentil 85 é um ponto de partida sólido para um SLE.

5. Traga para seus eventos Scrum

   Use o histórico de taxa de entrega no planejamento da sprint em vez de (ou junto com) velocidade. Verifique a idade do item de trabalho nas daily scrums. Revise as tendências de tempo de ciclo nas retrospectivas. Apresente o desempenho do SLE nas revisões da sprint.

Onde as métricas de fluxo se encaixam em cada evento Scrum

Essas métricas se tornam úteis quando você as conecta aos eventos que já está realizando. Planejamento da sprint: Use seu histórico de taxa de entrega para prever quantos itens você pode realisticamente puxar. "Completamos 6-9 itens por sprint nas últimas 8 sprints" é mais fundamentado do que debater totais de pontos de história. Para mais sobre como executar sessões de planejamento eficazes, confira nosso guia de planejamento de sprint. Daily scrum: Mude de atualizações de status para fluxo. "O que está envelhecendo?" é uma pergunta melhor do que "o que você fez ontem?" Se um item tem 7 dias de idade e seu tempo de ciclo do percentil 85 é 10 dias, a equipe deveria estar se concentrando nele. Revisão da sprint: Mostre aos stakeholders sua tendência de tempo de ciclo e desempenho do SLE. "Entregamos 85% dos itens em 10 dias nesta sprint, acima dos 72% do mês passado" constrói confiança através da transparência. Retrospectiva da sprint: É aqui que as métricas de fluxo compensam mais. Um diagrama de fluxo cumulativo mostra gargalos que são invisíveis em um gráfico burndown, como trabalho se acumulando em revisão de código ou uma fase de testes que fica sem recursos quando o QA é puxado para reuniões.

Métricas de fluxo vs. velocidade: não é uma briga

A velocidade não está quebrada, é apenas limitada. Funciona bem como uma ferramenta de planejamento interna para conversas de nível de sprint. O problema começa quando as equipes a usam para compromissos de entrega, a comparam entre equipes, ou a tratam como uma métrica de desempenho. As métricas de fluxo respondem às perguntas que a velocidade não pode:

• "Quando isso estará pronto?" Percentis de tempo de ciclo dão respostas probabilísticas.
• "Por que as coisas estão demorando tanto?" WIP e idade do item de trabalho mostram onde o trabalho está preso.
• "Podemos nos comprometer com esta data?" Simulações de Monte Carlo usando histórico de taxa de entrega dão níveis de confiança.

A abordagem prática: use ambas. Mantenha a velocidade para planejamento de sprint se funciona para sua equipe. Adicione métricas de fluxo para previsão de entrega e melhoria de processo.

Erros que pegam as equipes

Otimizar a taxa de entrega ao custo de tudo mais. Pressionar equipes para fechar mais itens leva a escolher trabalhos pequenos, dividir histórias artificialmente, ou cortar cantos na qualidade. A taxa de entrega é uma ferramenta de diagnóstico, não uma meta. Ignorar a idade do item de trabalho até ser tarde demais. O tempo de ciclo só diz sobre trabalho finalizado. Se você não está observando a idade dos itens em progresso, vai perder sinais de alerta. Coloque no seu quadro ou traga na daily scrum. Pular a Definição de Fluxo de Trabalho. Sem um entendimento compartilhado do que "iniciado" e "concluído" significam, seus dados são inconsistentes e suas métricas não são confiáveis. Não precisa ser perfeito, mas precisa existir. Medir tudo. Você não precisa de 15 gráficos. As quatro métricas de fluxo, um gráfico de dispersão de tempo de ciclo, e talvez um diagrama de fluxo cumulativo cobrirão 90% do que você precisa. Adicione complexidade apenas quando tiver uma pergunta específica para responder.

Como é o sucesso depois de alguns meses

Equipes que persistem com métricas de fluxo por 3-6 meses tendem a notar algumas coisas. O planejamento da sprint fica mais rápido porque a taxa de entrega dá um ponto de partida claro para capacidade. As retros produzem itens de ação mais específicos porque você está olhando dados em vez de sentimentos. A maior mudança geralmente é cultural. As equipes param de pensar em iniciar trabalho e começam a pensar em finalizá-lo. A pergunta muda de "o que devo pegar a seguir?" para "o que posso ajudar a levar até o fim?" Essa é a mudança que realmente faz a diferença. Ferramentas como o planning poker do Kollabe ajudam com o lado de estimativa do planejamento de sprint, mas as métricas de fluxo dão a previsibilidade de entrega que a estimativa sozinha não pode fornecer.