Cumulative flow diagram

A maioria dos líderes de engenharia consegue dizer que o squad está ocupado. Poucos conseguem dizer onde o trabalho está travando de verdade. Um diagrama de fluxo cumulativo dá essa visibilidade: ele mostra como os itens de trabalho se acumulam em cada etapa do seu pipeline de entrega ao longo do tempo, tornando os gargalos visíveis antes que eles comprometam um sprint. Esta página explica o que é um diagrama de fluxo cumulativo, como lê-lo e medi-lo, quais padrões são saudáveis ou preocupantes, e como agir com base no que você encontra.

Principais conclusões

• Um diagrama de fluxo cumulativo visualiza o número total de itens de trabalho em cada etapa do seu processo de entrega em um determinado período, tornando-o uma das ferramentas mais claras para identificar onde o fluxo quebra no pipeline do squad. Times que revisam o CFD regularmente conseguem detectar gargalos antes que eles virem compromissos perdidos.
• Para ler um CFD, meça a distância vertical entre duas faixas em qualquer ponto do tempo para ver o WIP daquela etapa, e meça a distância horizontal entre quando um item entra em uma faixa e sai de outra para estimar o cycle time. Nenhum benchmark publicado define um formato "bom" de CFD, mas um gráfico saudável mostra faixas de largura aproximadamente constante e uma inclinação ascendente estável na faixa "concluído".
• O erro mais comum que os times cometem com um diagrama de fluxo cumulativo é tratar uma faixa que se alarga como um problema de capacidade e adicionar mais players, quando o problema real é uma restrição de processo mais acima. Adicionar pessoas a uma etapa congestionada aumenta o WIP e geralmente piora o gargalo.
• O DevStats expõe dados de fluxo e throughput automaticamente ao se conectar ao seu issue tracker, com benchmarks comparando mais de 1.000 times de engenharia para você ver como a taxa de entrega do seu squad se posiciona. Inicie um teste gratuito e veja seus números em menos de dois minutos.

Definição de diagrama de fluxo cumulativo

Um diagrama de fluxo cumulativo (CFD) é um gráfico de área empilhada que mostra o número total de itens de trabalho em cada etapa de um fluxo de trabalho, plotado ao longo do tempo. Cada faixa colorida representa uma etapa, como backlog, em andamento, em revisão ou concluído. O gráfico torna imediatamente visível quando o trabalho se acumula em uma etapa específica ou quando o throughput geral desacelera.

Tecnicamente, um CFD é gerado a partir dos dados do seu issue tracker. A distância vertical entre duas faixas adjacentes em qualquer data equivale ao WIP daquela etapa. A distância horizontal entre quando um item entra em uma faixa e quando sai representa o cycle time aproximado. Times que conectam seus dados de issue cycle time a um CFD têm uma visão muito mais clara de onde o tempo está sendo perdido do que a velocidade do sprint sozinha oferece. Quando o fluxo de entrega é saudável, os stakeholders recebem cronogramas de release mais previsíveis e menos surpresas de última hora.

Por que o diagrama de fluxo cumulativo importa para times de engenharia

Sem um CFD, os gargalos ficam invisíveis até virarem emergências. Um squad pode estar cumprindo os compromissos do sprint no papel enquanto uma etapa de revisão acumula silenciosamente um backlog de duas semanas. Quando a lentidão aparece na velocidade ou nos prazos perdidos, a causa raiz já tem semanas de idade. O CFD traz esse sinal cedo, para você agir antes que o sprint já esteja perdido.

Para líderes de engenharia, o CFD se conecta diretamente aos KPIs mais importantes: entrega previsível, WIP sustentável e confiança dos stakeholders. Uma faixa "em revisão" que se alarga, por exemplo, é um sinal para examinar o seu processo de code review, não para adicionar mais players. O CFD também se encaixa bem no Flow framework e complementa as métricas do SPACE framework ao medir a eficiência dos processos, não a produção individual. Times que acompanham a saúde do sprint junto com o CFD obtêm indicadores antecipados de risco de entrega, não apenas a confirmação tardia do que já deu errado.

A medição é o ponto de partida. O engineering manager lê o padrão, aplica o contexto e decide o que mudar.

Como medir um diagrama de fluxo cumulativo

Um CFD é gerado a partir do seu issue tracker, como Jira, Linear ou GitHub Issues. Para cada data no intervalo de tempo escolhido, você conta o número total de itens que já entraram em cada etapa do fluxo. Esses totais são empilhados para criar as faixas de área. As principais medições que você lê no gráfico são o WIP (largura vertical da faixa em um ponto do tempo) e o cycle time aproximado (distância horizontal percorrida por um item entre as faixas). Você também lê o throughput pela inclinação da faixa "concluído": uma inclinação mais acentuada significa mais itens sendo concluídos por unidade de tempo.

Nenhum benchmark publicado define um formato ideal de CFD, porque o padrão correto depende do tamanho do time, das etapas do fluxo e do modelo de release. A tabela abaixo descreve níveis de sinal qualitativos. Você pode comparar seus padrões de fluxo com times semelhantes usando os benchmarks do DevStats.

Os benchmarks variam de acordo com o tamanho do time, a complexidade do código e o modelo de release. Use os padrões acima como sinais direcionais, não como limites rígidos.

Diagrama de fluxo cumulativo na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que o squad estava perdendo as metas do sprint de forma consistente, mesmo com alta atividade. Ela gerou um CFD cobrindo as oito semanas anteriores e viu a faixa "em revisão" crescendo a cada sprint enquanto a inclinação da faixa "concluído" estava quase plana. Os dados apontavam para uma restrição de processo específica: pull requests ficavam em revisão por quatro ou mais dias antes de serem mergeados. Ela não precisava de mais players. Ela precisava de um processo de revisão diferente.

Ela introduziu uma norma no squad de primeira revisão no mesmo dia para qualquer PR aberto há mais de 24 horas e definiu um limite de WIP de três itens por player na etapa de revisão. Nos três sprints seguintes, ela acompanhou o CFD junto com o PR cycle time para confirmar que a faixa estava se estreitando. A inclinação da faixa "concluído" ficou mais acentuada, a entrega se tornou mais previsível e a confiança dos stakeholders nos compromissos do time melhorou. O CFD mostrou onde olhar. Ela decidiu o que fazer.

Como melhorar o seu diagrama de fluxo cumulativo

1. Defina limites explícitos de WIP por etapa. Identifique a faixa mais larga no seu CFD e limite o número de itens permitidos naquela etapa a qualquer momento. Os limites de WIP forçam o squad a terminar o trabalho antes de puxar novos itens, o que estreita a faixa e acelera o fluxo. Fique atento ao gargalo se deslocar para uma etapa adjacente depois de impor o limite.
2. Audite as etapas do seu fluxo para garantir precisão. Um CFD só é útil se os dados que o alimentam forem confiáveis. Se os players não estiverem movendo os cards entre as etapas de forma consistente, as faixas vão representar mal o fluxo real. Faça uma auditoria de um sprint para confirmar que as transições de etapa no seu issue tracker refletem mudanças reais no estado do trabalho.
3. Combine o CFD com dados de cycle time. Uma faixa que se alarga mostra onde o trabalho está se acumulando. O issue cycle time mostra quanto tempo os itens individuais estão passando lá. Usar os dois juntos ajuda a distinguir entre um aumento de novos trabalhos e uma queda no throughput de uma etapa específica.
4. Revise o CFD no início de cada retrospectiva de sprint. Leve as últimas duas a quatro semanas de dados do CFD para a retro. Peça ao squad para identificar a faixa mais larga e propor uma mudança de processo para resolvê-la. Isso mantém a conversa ancorada em dados de fluxo, não em percepções subjetivas.
5. Monitore mudanças de alocação junto com o CFD. Se uma faixa se alarga depois que um membro do squad muda de projeto, isso é um sinal de capacidade que vale examinar pelos dados de alocação. O CFD mostra o sintoma. Os dados de alocação ajudam a identificar se decisões de recursos são a causa.

Diagrama de fluxo cumulativo vs. burndown chart

Os dois gráficos acompanham o trabalho ao longo do tempo, mas respondem a perguntas diferentes: um diagrama de fluxo cumulativo mostra onde o trabalho está se acumulando em todas as etapas simultaneamente, enquanto um burndown chart mostra quanto trabalho ainda resta em relação a uma meta dentro de um sprint ou janela de release fixo.

Use um burndown chart para gerenciar um sprint em andamento. Use um diagrama de fluxo cumulativo para entender os padrões sistêmicos de fluxo que determinam se o seu squad consegue cumprir esses sprints de forma confiável.