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.

Quer saber mais sobre métricas? Dá uma olhada nesses artigos aqui:

Sobre métricas

Métricas de gestão de times e empresas

Métricas de Produto

Métricas de Fluxo (Organização de Times)

Métricas Técnicas

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.

As ferramentas de Inteligência Artificial (IA) já são uma realidade. Todavia, como saber qual escolher. Neste artigo quero apresentar os atuais modelos de IA que temos disponíveis para te ajudar nessa escolha. Antes vamos a alguns avisos importantes 1. A…

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

Já tem um bom tempo que não falo sobre assuntos técnicos por aqui. No entanto, outro dia tivemos que pagar uma dívida técnica bem alta e isso acendeu alguns alertas. Os produtos dos meus times sofrem atualizações constantes seja por…

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

Sempre que falamos de gestão de produtos, a discussão sobre os papéis de Product Owner (PO), Product Manager (PM) e Gerente de Projetos (GP) ressurge. Muito se fala sobre as vantagens da separação deles. Mas pouco se fala sobre o…

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

Em 2008 comecei a utilizar Métodos Ágeis. Já faz tanto tempo que parece que eu nunca trabalhei de outras formas, porém já passei pelo Método Cascata clássico, Rational Unified Process (RUP), PMBOK e até a implantação do MPS.Br. Pelo mais…