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).
Neste Artigo
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.
Nosso time está trabalhando junto há 25 dias e o CFD abaixo apresenta o fluxo dos itens ao longo desse tempo.
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:
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.
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
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.
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.
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.
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.
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 |
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:
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:
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.
| Semana | Dias | Itens |
| 1 | 1 – 5 | 18 |
| 2 | 6-10 | 0 |
| 3 | 11-15 | -3 |
| 4 | 16-20 | 8 |
| 5 | 21-25 | 8 |
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:
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.
