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
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)
É 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
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)
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
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
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”)
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)
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.
