Métricas Ágeis no Cumulative Flow Diagram (CFD): como analisar

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Compartilhe:

No artigo anterior, falamos sobre como montar um Gráfico de Fluxo Cumulativo, do inglês Cumulative Flow Diagram – CFD. Ali também falamos de como interpretar algumas informações que este poderoso gráfico nos dá. Agora vamos ver as métricas ágeis no CFD.

Spoiler, temos também o Como identificar padrões (e evitar disfunções) no Cumulative Flow Diagram (CFD).

Cenário – Cumulative Flow Diagram

O nosso fluxo de valor é composto por uma sequência de estágios de Ação (Action Stages) e Espera (Waiting Stages). Podemos dizer que os estágios de ação estão no gerúndio e as de espera estão no particípio. São eles:

Espera: Backlog

Ação: Refinando

Espera: Priorizado

Ação: Construindo

Espera: Construído

Ação: Avaliando

Espera: Avaliado

Ação: Entregando

Estado final: Entregue. 

Figura 1: Fluxo de valor mapeado em um Quadro de Tarefas.

Nosso time está trabalhando junto há 25 dias e o CFD abaixo apresenta o fluxo dos itens ao longo desse tempo.

gráfico CFD
Figura 2: Gráfico CFD do time exemplo no vigésimo-quinto dia.

Lead time (customer lead time) no Cumulative Flow Diagram

É a métrica de eficiência mais importante. Ela define o time to market do nosso produto ou serviço. É o tempo decorrido desde que o item entra no ponto de compromisso até ele ser entregue na mão do cliente (disponível para ele utilizar, se desejar).

Ponto de compromisso

Para você ter essa métrica, primeiro é preciso definir qual o seu ponto de compromisso. Essa é a etapa em que o time se compromete a desenvolver o item de valor e entregá-lo como incremento de produto ou serviço.

Atenção: muitas das vezes será importante deixar esse ponto de compromisso explícito para gestores, clientes e stakeholders. Isso ajuda a gestão de expectativas e impede que sejam criadas expectativas irreais.

No nosso cenário apresentado na Figura 1, o Ponto de Compromisso é quando o item passa da coluna Refinando para Priorizado. Isso significa que o lead time só começa a contar quando o item chega em Priorizado.

Ponto de entrega

Ponto de entrega é o momento em que o item sai da mão da empresa e é entregue para o cliente utilizar. Isso é muito importante porque o nome completo e correto do lead time é Customer Lead Time (tempo de espera do cliente, em tradução livre). 

“Mas o meu time não é ponta-a-ponta. Eu entrego para outro time que entrega para outro time que entrega para outro e só depois disso que o meu cliente recebe o incremento do produto ou serviço. Devo incluir o tempo desses times externos (dependências externas) no meu lead time?”

Sim. Seu cliente não tem culpa da forma como sua empresa se estruturou. É o tempo de espera dele.

“Poxa vida, meu time ‘entrega’ em 10 dias, mas tem 20 dependências externas, 1 janela, 7 freezes, autorização do gerente, coordenador, presidente, até o Papa tem que autorizar. No final demora uns 5 meses para chegar na pessoa que usa meu incremento. Qual o meu lead time?”.

Cinco meses, 150 dias se preferir. Há outras métricas para você separar o tempo do seu time das dependências externas, mas nesse caso o lead time, ou melhor customer lead time, é de 5 meses.

Não caia na tentação, erro e pecado que muitos times cometem escondendo o verdadeiro lead time só porque a métrica é “feia”.

A briga que você não enfrenta hoje, é a guerra que você terá que lutar amanhã

Andressa Chiara

No gráfico

O Customer lead time pode ser visto de qualquer ponto onde haja a entrada de um item no ponto de compromisso, até o cruzamento dele pelo Ponto de Entrega. Vamos ao exemplo:

Figura 3: O Customer Lead time, mais conhecido como lead time apenas traçado no CFD.

Temos duas linhas de Lead time no nosso CFD. No primeiro momento, vermelho, o lead time era de 11 dias (chegou no ponto de entrega no dia 21 e atingiu o ponto de compromisso no dia 10, então 21 – 10 = 11).

No segundo momento, verde, o lead time melhorou e passou para 7 dias (ponto de entrega, dia 23. Já o ponto de compromisso foi no dia 16. Logo 23 – 16 = 7).

A melhora pode ser percebida mesmo sem a conta, pois há uma redução do tamanho da linha entre o primeiro momento marcado pela linha vermelha e o segundo momento marcado pela linha verde.

Kanban System Lead Time

“Meu time não é ponta-a-ponta. Eu entrego para outro time e esse time entrega para o cliente”. Nesse caso há uma métrica que você pode utilizar. Ela mede o tempo de desenvolvimento no qual os itens ficam no seu sistema (seu time).

Ele encerra sua contagem quando o item chega na primeira etapa não limitada. Normalmente porque é aberta uma demanda para um time externo de entrega (delivery) o qual não temos nenhum tipo de gestão.

Sobre esse relacionamento, veja este artigo: Resolvendo as dependências externas ao time

Para medirmos o Kanban System Lead time, ou apenas System Lead time, traçamos a reta horizontal entre o ponto de compromisso até a primeira coluna não limitada. No nosso exemplo, ela seria a coluna referente à etapa Entregando.

Figura 4: Linha vermelha indicando o Kanban System Lead Time começando na etapa Priorizado e terminando na saída de Construído para Entregue. O lead time está logo abaixo na linha tracejada.

Cycle time no Cumulative Flow Diagram

Essa é uma métrica fundamental para descobrir onde é o gargalo do nosso fluxo e qual o impacto dele. Cycle time é medido com uma reta horizontal entre o início e o fim de uma etapa.

Atenção sobre o ponto em que uma etapa se inicia.  Você deve saber qual é o momento exato da passagem de bastão (handoff). Para tal, imagine que no nosso exemplo tenhamos um time formado apenas por ultra especialistas. Cada um só faz a sua parte no processo e não ajuda ninguém.

A pergunta que você deve fazer é: Qual é o ponto em que o ultra especialista da construção informa que o trabalho dele acabou (não há mais nada que ele possa fazer) e agora é a vez do ultra especialista da avaliação (e só ele pode fazer)? No nosso exemplo os ciclos ficam assim:

Ciclo de construção: priorizado + construindo

Ciclo de avaliação: construído + avaliando

Ciclo de entrega: avaliado + entregando

Ficou difícil? Você pode enxergar a fila de espera com outro nome para facilitar:

Ciclo de construção: Disponível para Construção (priorizado) + construindo

Ciclo de avaliação: Disponível para avaliação (construído) + avaliando

Ciclo de entrega: Disponível para entrega (avaliado) + entregando

Figura 5: Linhas representando os cycle times de três etapas do fluxo de valor. 

Aging (envelhecimento) no Cumulative Flow Diagram

Beleza, mas e o tempo que o item fica no backlog antes do compromisso. Podemos deixar os itens lá eternamente? Sim e não. Teoricamente não é um problema para o seu fluxo uma vez que enquanto o item está antes do ponto de compromisso ele não impacta o lead time. Todavia, ter um backlog com muitos itens torna o trabalho de refinamento e priorização um inferno. 

Imagine que você quer viajar e no seu roteiro só há 3 cidades possíveis: Lisboa, Madri e Roma. Escolha o que você pretende conhecer e priorize qual cidade você quer conhecer primeiro, a segunda e a terceira.

Agora, imagine que aumentamos para dez cidades. Já é mais difícil priorizar. Qual a diferença entre a quarta e a quinta cidade? A sétima e a oitava? Agora imagine que são 100 cidades. Fica mais difícil ainda. 

Aging é medido antes do ponto de compromisso até a entrega. Todavia, seu uso mais comum é o período que os itens ficam no backlog justamente para estabelecer um possível parâmetro de descarte.

No CFD o aging total é visualizado através de uma linha horizontal entre a entrada no backlog até a entrega para o cliente. Já o envelhecimento do item no backlog é o tempo em que os itens ficam no backlog até a saída dele para a próxima etapa. 

Figura 6: Aging total (envelhecimento total) e Backlog Aging (envelhecimento do backlog).

Work in Progress no Cumulative Flow Diagram

As medidas que vimos até o momento estão relacionadas ao tempo (Eixo X), mas também há informações valiosas no Eixo Y do CFD. Uma delas é o Trabalho em Progresso.

Mais conhecida pela sua sigla em inglês WIP (Working In Progress). É uma linha vertical que começa no ponto de compromisso e vai até o ponto de entrega do item.

Você pode ver o WIP de todo o fluxo, o WIP de uma etapa ou até mesmo um estágio específico da etapa.

Figura 7: Trabalho em Progresso. Linha vermelha mostra o WIP Total começando em Priorizado (Ponto de Compromisso) e terminando quando o item atravessa o Ponto de Entrega. Temos o WIP de Avaliação (Construído + Avaliando) e o WIP específico apenas de Construído.

Variação de escopo no Cumulative Flow Diagram

Uma medida menos famosa, mas que causa um bom impacto no envelhecimento e dificulta tanto o refinamento quanto a priorização é a variação do escopo. Mal comparando é como se fosse o WIP do Backlog, mas, por não ser trabalho em progresso seria errado chamá-lo assim. Toda vez que um item entra no backlog, a área aumenta e quando é descartado ela reduz.

Figura 8: Variação no CFD com Aumento e Redução de Escopo

Caso essa variação aconteça após essa etapa de backlog, pode ser um indicativo de refluxo (tratado neste post) ou descarte tardio de itens após o Ponto de Compromisso. Ambos indicam alguma disfunção no fluxo. É melhor investigar o que está acontecendo.

Vazão (throughput, Delivery Rate, “velocidade”) no Cumulative Flow Diagram

Seu nome é mais conhecido em inglês throughput. Muitas das vezes é chamado de velocidade. Entretanto, este último não é o melhor termo, pois velocidade é uma medida de distância sobre tempo. Por exemplo: km/h ou m/s. Vazão é o nome mais correto.

A vazão de um fluxo é a quantidade de itens entregues para um cliente em um determinado período (dia, semana, quinzena, mês, trimestre, sprint…). Para visualizar no CFD, pegue o período e veja quantos itens foram entregues para o cliente.

Figura 9: Vazão da semana 3 e semana 4 apresentadas no CFD.

Nesse time, considerando que começamos a contar a vazão a partir do dia 1 teríamos:

Semana Dias Itens
1 1 – 5 0
2 6-10 0
3 11-15 2
4 16-20 4
5 21-25 14
Tabela 1: Vazão semanal de itens nos 25 dias do CFD

Qual é a vazão média desse time?

Você pode considerar todas as semanas. Mesmo as iniciais em que não houve entrega. No caso:

Equação 1: Vazão média igual a 4 itens por semana. Computando inclusive as semanas iniciais em que não houve entrega.

Particularmente não gosto de incluir essas semanas iniciais na vazão. No início do desenvolvimento é comum que ainda exista muito preparo e pode ser que demore algum tempo para que o time comece a entregar.

Eu, Avelino, prefiro contar a partir da semana em que o time fez a primeira entrega. Depois disso, caso existam semanas em que o time não entregue nada, elas também entram na equação. Se você gostou da ideia, nesse caso a vazão do time seria:

Equação 2: Vazão média é aproximadamente 6 itens por semana. Descontando as semanas iniciais em que não houve entrega.

Taxa de Entrada (Taxa de Chegada) no Cumulative Flow Diagram

Uma reclamação bem comum que ouvimos dos times é: “A prioridade muda o tempo todo”. Tem uma variante dessa frase para os times que usam Scrum: “a prioridade muda no meio da Sprint”.

Normalmente isso é um sintoma de uma disfunção. Esse problema passa a acontecer porque o nosso lead time, tempo de espera do cliente (também pode ser compreendido como tempo de desenvolvimento do item) está maior do que a necessidade do negócio.

A Taxa de Entrada, também chamada de Taxa de Chegada de itens, é a quantidade de itens que chegam em um período. Vamos ver como ela aparece no CFD.

Figura 10: Taxa de Entrada (ou Taxa de Chegada) das semanas 3 e 4 representadas no CFD
Semana Dias Itens
1 1 – 5 18
2 6-10 0
3 11-15 -3
4 16-20 8
5 21-25 8
Tabela 2: Taxa de Entrada semanal de itens nos 25 dias do CFD

Por que ela é importante?

Na seção anterior falamos sobre a vazão da quantidade de itens entregues por período. Logo, podemos ter uma relação entre a quantidade de itens que entram e que saem do fluxo.

Se muitos itens chegam, mas poucos vão embora, temos um desequilíbrio entre essas duas pontas. Esse desequilíbrio acaba fazendo com que alguns stakeholders importantes comecem a “forçar” novos itens direto para o desenvolvimento.

Algumas vezes pode ser uma questão de oportunidade de negócio, outras pode ser para corrigir um problema ou até mesmo uma disputa política. 

Se fizermos a conta da Taxa de Entrada desses 25 dias, veremos que há um equilíbrio entre a vazão e a taxa de entrada:

Equação 3: Taxa de Entrada de novos itens é aproximadamente 6 itens por semana.

Cuidado com o Backlog fantasma

Esse é um problema comum para muitos times que trabalham com pedidos de manutenção através de bug issues (sistema de tickets).

Quando a quantidade de tickets aumenta, começam as reclamações: “Essas pessoas abrem um ticket por qualquer coisa”, “Esse usuário não tem mais nada para fazer”, “TEM QUE TER ALGUÉM PARA FILTRAR ESSES TICKETS”. Essa última costuma a ser a gênesis do backlog fantasma 👻👻👻👻

A tal pessoa, normalmente o Product Owner ou um gestor, passa a “filtrar” os tickets e só coloca no backlog do time aquilo que ele acredita ser relevante.

Agora, imagine que existem 40 pedidos de 40 pessoas diferentes. Esse “Filtrador” move apenas 5 itens para o backlog do time. Parece que está tudo OK, mas, as outras 35 pessoas têm expectativa de que seus pedidos serão atendidos.

Mais cedo ou mais tarde, elas começam a cobrar. No frigir dos ovos, o backlog desse time é composto pelos 35 itens que estão nesse backlog “fantasma” mais os 5 itens que foram movidos para o backlog “vivo” e mais os itens que já estavam lá. 

Conclusão

Essas foram as métricas de eficiência que podemos ver através do CFD. Lembrando que é importante que compreendamos as informações do CFD antes de entender as métricas.

Agora que você já conhece as métricas, aprenda a identificar os padrões no CFD aqui. Para mais conteúdos sobre o assunto, não deixe de acompanhar nosso blog. 


Quer aprender CFD na prática e muito mais sobre Kanban? Faça esse treinamento de Kanban System Design aqui na K21. Nos vemos em breve e até a próxima.

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

É uma pergunta comum em diversos times ágeis: Temos capacidade para atender a demanda? A resposta é não. Como diz Rodrigo de Toledo: “No trabalho do conhecimento, a demanda sempre irá superar a nossa capacidade de atendê-la.”. O desafio é…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…