Flow metrics

A maioria dos líderes de engenharia consegue dizer quantos story points o squad entregou no último sprint. Poucos conseguem dizer onde o trabalho travou de verdade. Flow metrics dão essa visibilidade: elas medem como o trabalho se move pelo seu sistema de entrega, desde o momento em que uma ideia é iniciada até o momento em que vai para produção. Esta página cobre a definição, como medir cada flow metric, benchmarks, um exemplo real e como o DevStats mostra esses dados automaticamente.

• Flow metrics são um conjunto de quatro medições (flow velocity, flow time, flow efficiency e flow load) que descrevem como o trabalho se move por um sistema de entrega de software. Elas deslocam o foco do output individual para a performance do sistema como um todo, que é onde a maioria dos problemas de entrega realmente vive.
• Flow metrics são calculadas a partir de dados de issues e itens de trabalho ao longo do seu pipeline de entrega. Não existem benchmarks universais publicados para as quatro métricas, mas flow efficiency abaixo de 15% e flow time acima de 30 dias são amplamente considerados sinais de gargalos sistêmicos. Os benchmarks variam conforme o tamanho do time e o modelo de release.
• O erro mais comum dos times com flow metrics é medir flow velocity de forma isolada. Um squad que entrega mais itens por sprint enquanto o flow time sobe e a flow efficiency cai não está melhorando. Velocity sem as outras três métricas é enganosa e pode mascarar uma disfunção crescente no seu sistema de entrega.
• O DevStats mostra throughput, issue cycle time e outros sinais de flow automaticamente, conectando ao seu provedor Git e ao seu issue tracker, com benchmarks comparados a mais de 1.000 times de engenharia. Comece um teste gratuito e veja seus números em menos de dois minutos.

Definição de flow metrics

Flow metrics são um conjunto de quatro medições que descrevem com que eficiência o trabalho se move por um sistema de entrega de software: flow velocity (quantos itens são entregues por unidade de tempo), flow time (quanto tempo cada item leva do início até a conclusão), flow efficiency (a proporção entre o tempo de trabalho ativo e o tempo total decorrido) e flow load (o número de itens em andamento ao mesmo tempo). Juntas, elas oferecem uma visão sistêmica do seu processo de entrega.

O framework foi popularizado por Mik Kersten em Project to Product e tem base nos princípios de manufatura lean aplicados ao software. A flow efficiency é calculada assim: Flow Efficiency = Tempo Ativo / (Tempo Ativo + Tempo de Espera). Quando o flow load está alto e a flow efficiency está baixa, você tem um problema de congestionamento, não de capacidade. Melhorar as flow metrics se correlaciona diretamente com um time-to-market mais rápido e compromissos de entrega mais previsíveis para os stakeholders.

Times que querem conectar flow metrics ao seu framework de medição mais amplo podem combiná-las com DORA metrics, que medem frequência de deployment, lead time for changes, taxa de falha em mudanças e tempo médio de recuperação. Os dois frameworks se complementam: DORA mede a saúde do pipeline de entrega, enquanto flow metrics medem o sistema de gestão do trabalho upstream.

Por que flow metrics importam para times de engenharia

Quando squads não acompanham flow metrics, os gargalos ficam invisíveis. O trabalho se acumula em revisão, em staging ou aguardando uma dependência, e o único sinal que a liderança recebe é um sprint perdido. Quando a retrospectiva do sprint traz o problema à tona, o atraso já se multiplicou por vários itens de trabalho e o time já está atrasado no próximo ciclo.

Flow metrics se conectam diretamente aos KPIs pelos quais líderes de engenharia são responsáveis. Entrega previsível melhora a confiança dos stakeholders. Flow time menor encurta os ciclos de feedback com clientes. Flow efficiency saudável sinaliza que o squad está gastando tempo construindo, não esperando. Acompanhar o flow load ajuda você a perceber o crescimento descontrolado do WIP antes que ele vire burnout. Você pode ver tendências de throughput junto com dados de cycle time para entender se o squad está entregando mais itens ou apenas iniciando mais itens sem terminá-los.

Flow metrics se alinham com a ênfase do SPACE framework em medir sistemas e processos, não output individual. A medição é o ponto de partida. O líder de engenharia é quem lê os dados, aplica contexto e decide o que mudar.

Como medir flow metrics

Flow metrics são calculadas a partir de dados de itens de trabalho no seu issue tracker, normalmente Jira, Linear ou GitHub Issues, combinados com timestamps do seu provedor Git e do pipeline de CI/CD. Você precisa de timestamps de início (quando o trabalho foi iniciado), timestamps de conclusão (quando foi entregue) e logs de transição de estado (para calcular tempo ativo versus tempo de espera). Sem dados de transição de estado, você consegue calcular flow time e flow velocity, mas não flow efficiency.

Nenhum benchmark publicado cobre as quatro flow metrics da forma como o relatório State of DevOps do DORA cobre frequência de deployment e lead time. A tabela abaixo reflete faixas qualitativas amplamente citadas por profissionais e pesquisadores de entrega de software Lean. Os benchmarks variam conforme o tamanho do time, a complexidade do código e o modelo de release. O recurso de benchmarks do DevStats permite comparar seus sinais de flow com times de perfil semelhante.

Essas faixas são guias qualitativos, não limites absolutos. Um squad que entrega features grandes e complexas naturalmente terá flow times maiores do que um que entrega mudanças pequenas e incrementais. O contexto sempre importa na hora de interpretar os números.

Flow metrics na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que a velocity do sprint parecia estável, mas o time continuava perdendo datas de release. Ela puxou os dados de flow time dos últimos três meses e descobriu que o flow time mediano para itens de backend tinha subido de 9 para 22 dias. A flow efficiency tinha caído para 18%. Os dados apontavam para um padrão específico: os itens ficavam parados em code review por uma média de seis dias antes de receber uma primeira resposta. Ela não estava olhando para quem estava demorando para revisar. Ela estava olhando para uma lacuna no processo.

Ela criou um acordo de squad: todos os PRs abertos recebem uma primeira revisão em até um dia útil. Ela também limitou o WIP a três itens por player. Nas seis semanas seguintes, ela acompanhou o PR cycle time e o flow time juntos. O flow time mediano caiu para 13 dias. A flow efficiency voltou para 31%. Os atrasos nas datas de release pararam. A intervenção foi dela. Os dados disseram onde olhar.

Como melhorar flow metrics

1. Defina um limite de WIP por player e faça valer. Flow load alto é o preditor mais confiável de flow efficiency ruim. Quando players estão gerenciando quatro ou cinco itens ao mesmo tempo, o context-switching infla o tempo de espera de todos eles. Comece com um limite de dois a três itens ativos por player e ajuste conforme o tamanho dos itens. Acompanhe o flow load semanalmente, não só no final do sprint.
2. Audite seus estados de espera, não seu trabalho ativo. A maior parte do flow time se perde nas transições: esperando revisão, esperando QA, esperando um time de dependência. Mapeie cada estado no seu issue tracker e calcule o tempo médio gasto em cada um. O estado de espera mais longo é o seu primeiro alvo. Isso é uma auditoria de processo, não uma avaliação de performance.
3. Reduza o tempo de fila de code review com SLAs explícitos. O tempo de espera por revisão é o gargalo de flow mais comum em squads com mais de 10 players. Um acordo de squad que garante primeira revisão de todos os PRs em até 24 horas reduz o flow time de forma consistente sem precisar contratar mais pessoas.
4. Quebre itens grandes em unidades menores e entregáveis. Itens que levam mais de cinco dias para concluir inflam as médias de flow time e tornam a melhoria da flow efficiency mais difícil. Trabalhe com o squad para definir um tamanho máximo de item antes do sprint planning. Itens menores também melhoram a acurácia do planejamento, e esse efeito se acumula ao longo do tempo.
5. Revise flow metrics no nível do squad nas syncs semanais, não só nas retrospectivas. Flow time e flow efficiency são indicadores defasados, mas revisá-los semanalmente dá sinal suficiente para corrigir o curso dentro do mesmo sprint. O DevStats mostra esses sinais automaticamente para você passar a reunião discutindo intervenções, não coletando dados.

Flow metrics vs. DORA metrics

Flow metrics e DORA metrics são frequentemente mencionadas juntas, mas medem camadas diferentes do sistema de engenharia. DORA metrics focam no pipeline de deployment: com que frequência você faz deploy, quanto tempo as mudanças levam para chegar à produção, com que frequência os deployments falham e com que rapidez você se recupera. Flow metrics focam no sistema de gestão do trabalho: como os itens se movem do backlog até a conclusão, onde eles esperam e com que eficiência o squad opera antes do deployment.

Use flow metrics para diagnosticar problemas de entrega upstream e DORA metrics para avaliar a saúde do pipeline e a confiabilidade. Os dois frameworks juntos dão uma visão completa do seu sistema de engenharia.