Com as As Métricas Ágeis comuns ao upstream, midstream e downstream encerrarmos a série sobre Métricas Ágeis no Fluxo de Trabalho. Aqui reuni oito medidas comuns à essas fases.
Você pode ler os outros artigos da série:
Fluxo de Trabalho: o upstream, midstream e downstream
Métricas Ágeis: Midstream e Downstream
Neste Artigo
As Métricas Ágeis comuns ao upstream, midstream e downstream são:
Customer Lead Time (Tempo de Espera do Cliente) *
É o tempo decorrido desde que recebemos o item no nosso fluxo de trabalho (Ponto de Recebimento da Demanda). Pode ser o pedido de um cliente ou criação de uma opção, até ele ser entregue para o cliente (Ponto de Entrega). Vai da descoberta (discovery) à entrega (delivery).
| Dado: Customer Lead Time = EECLT Data de Recebimento da Demanda = DRD Data em que o Item chegou no Ponto de Entrega = DE Para toda opção que chegou no Ponto de Recebimento da demanda, se tornou um item de trabalho comprometido e foi entregue = x ∀x: CLT= DE – DRD |
Total Aging (Envelhecimento Total)
Muito parecida com o Customer Lead Time (CLT), porém o CLT só pode ser contabilizado quando o item de trabalho chega no Ponto de Entrega. Então, o Aging Total server para saber quanto tempo de existência os itens que estão perambulando pelo fluxo.
Quando o item chega no Ponto de Entrega, o CLT e o Aging Total são idênticos.
| Dado: Total Aging = TA Data de Recebimento da Demanda = DRD Data em que o Item chegou no Ponto de Entrega = DE Hoje Para toda opção que surgiu, se tornou um item de trabalho comprometido e foi entregue = x ∀x: TA = (DE ^ Hoje) – DRD |
Aqui mais uma vez cabem todas as recomendações já escritas no Customer Lead Time.
Lead Time (Tempo de Espera)
Há muito debate sobre se essa é a melhor nomenclatura, mas não está no escopo deste artigo dissertar sobre o tema. O Lead Time, muitas vezes chamado de Cycle Time, é o tempo de um item em uma etapa do fluxo. Você pode utilizar qualquer etapa do fluxo, inclusive você pode agrupar etapas. O Lead Time é uma medição entre o ponto A até um ponto B que você define.
É comum que essa medição seja utilizada para avaliar os tempos que o item fica em determinadas etapas do fluxo para compreender onde estão os pontos de gargalo. Ou seja, desde o momento em que o item está disponível para ser executado pelas pessoas responsáveis pela etapa. Até o momento em que eles agregam valor ao item e passam-no para a próxima etapa. É como se fosse uma passagem de bastão em uma corrida de revezamento. Por isso é muito importante saber o momento em que a “passagem de bastão” ocorre.
Para entender o momento dessa passagem de bastão você tem que entender como as colunas de ação e espera estão agrupadas no seu fluxo. Pode ser de forma sistemática como nas imagens apresentadas até o momento ou de forma semântica conforme nas imagens abaixo.
Quadros Sistêmicos
No quadro sistêmico temos a passagem de bastão no término da execução. Tradicionalmente são colunas que estão no tempo verbal Particípio: “Analisado, Estudado, Avaliado, Construído, Testado…” Quando o item chega nessa coluna acontece a sinalização de que o responsável já acabou seu trabalho sobre o item (feito) e ele está disponível para ser puxado (A fazer) pelo próximo responsável. Por isso o chamamos de sistêmico. O trabalho não é jamais empurrado para a próxima etapa e sim sinalizado para ser puxado para a próxima etapa. Por exemplo, o A fazer de Avaliação é a coluna Construído que está na etapa de Construção.
Uma característica desse tipo de quadro é que as colunas são arrumadas sempre no formato: Ação – Espera.
| Dado: Lead Time = LT Data em que o item chegou na coluna de espera na etapa anterior = DEA Data em que o Item saiu da coluna de execução da etapa corrente = DSC Para toda opção que chegou na coluna de espera na etapa anterior e saiu da coluna de execução da etapa corrente = x ∀x: LT = DSC – DEA |
Quadros Semânticos
Já o quadro semântico é exatamente o que o nome diz. Todo o trabalho da etapa está dentro daquela etapa com os nomes que se referem à etapa. A passagem de bastão acontece quando eu empurro o item de trabalho para a próxima etapa. Tradicionalmente são colunas que estão no tempo verbal Infinitivo: A Analisar, Para Estudar, Avaliar, Disponível para Construir… Quando o item chega nesta coluna, ele já está disponível para ser executado (A fazer) pelo próximo responsável. Uma característica desse tipo de quadro é que as colunas são arrumadas sempre no formato: Espera – Ação.
Uma vez definido o tipo de quadro que o seu time utiliza, podemos conhecer o início e fim de cada ciclo e calcular o Lead Time de cada etapa.
| Dado: Lead Time = LT Data em que o item chegou na coluna de espera na etapa corrente = DEC Data em que o Item saiu da coluna de execução da etapa corrente = DSC Para toda opção que chegou na coluna de espera na etapa anterior e saiu da coluna de execução da etapa corrente = x ∀x: LT = DSC – DEC |
Throughput (Vazão)
É a quantidade de itens que sai de uma etapa e vai para a próxima dividida por uma unidade de tempo. Por exemplo, a vazão de construção para avaliação é de 10 itens por semana. A vazão de avaliação para entrega é de 2 itens por mês.
Essa é outra métrica cuja nomenclatura é um tanto confusa. Primeiro porque ela recebe nomes especiais na entrada e saída do fluxo. Como já visto neste artigo (taxa de entrada e taxa de entrega). Segundo por causa da nomenclatura adotada pelo Scrum que também já foi abordada quando falamos sobre a taxa de entrega.
| Dado: Vazão = i vazão Período (dia, semana, Sprint…) = período opções ou itens entregues no término da etapa = oiet i vazão = ∑(oiet) / período |
Work in Progress (Trabalho em Progresso)
Mais conhecido pela sigla WIP, é a quantidade de itens de trabalho que estão no nosso fluxo. Contam aqui todos os itens do upstream que já saíram da piscina de opções até os itens chegaram no ponto de entrega. É cada item de trabalho ou opção iniciado e que ainda não tenha sido concluído, descartado ou abortado.
| Dado: Work in Progress do Fluxo = WIP fluxo Opções que fizeram a primeira movimentação no Upstream = opçõesM1 Itens de Trabalho não encerrados (descartados, abortados ou entregues = itensnE opções ou itens entregues no término da etapa = oietWIPf= ∑(opçõesM1) + ∑(itensnE) Se necessário para alguma análise mais específica, é possível fazer medições nas etapas do fluxo. UPSTREAM Work in Progress do Upstream = WIPUpstream Opções que fizeram a primeira movimentação no Upstream e não chegaram no Ponto de Comprometimento = opçõesM1nPC WIPUpstream= ∑(opçõesM1nPC) DOWNSTREAM Work in Progress do Downstream = WIPDownstream Opções que chegaram no Ponto de Comprometimento, mas não encerrados = itensPCnE WIPDownstream= ∑(itensPCnE) |
Todos os itens dentro da caixa cinza são contabilizados como WIP. Inclusive os bloqueados. No total, o WIP deste fluxo é igual a 16. 4 Opções no Upstream (Discovery) mais 9 no Midstream e 3 no Downstream (Delivery).
Consequentemente não entram na contagem da Sprint as opções na Piscina de opções, pois ainda são manifestações de desejos dos stakeholders, sem nenhuma tratativa feita pelo time. Opções descartadas, pois não estão mais no fluxo. Assim como os itens abortados, pelos mesmos motivos. Os itens entregues também já saíram do fluxo e não estão mais em progresso.
WIP Limit (Limite de Trabalho em Progresso)
O WIP Limit não é uma métrica em si e sim uma restrição arbitrada pelo time / squad para cada etapa do fluxo. Ele pode ser utilizado para diversos objetivos: fazer com que o fluxo de trabalho se torne contínuo, evitar desperdício, tratar gargalos, incentivar pareamento, forçar a movimentação, e outros. Esses limites evitam que alguma etapa do fluxo de torne um grande amortecedor e estoque o trabalho em progresso. Isso é importante porque todo estoque tem depreciação, mesmo o de produto inacabado. Isso também inclui o estoque do trabalho do conhecimento.
No caso o limite de WIP da entrega é inexistente. O sinal de infinito (∞) só está ali para fins didáticos. Itens descartados, itens abortados, itens entregues não possuem limite de WIP. Eu já vi 1 time limitar a piscina de opções em um contexto bem específico de criação de produto físico (hardware). Mesmo trabalhando com outros times de produtos físicos, essa foi a única vez.
Capacity (Capacidade)
Em um trabalho fabril, a capacidade de produção é definida pela quantidade de espaços disponíveis na esteira e nos equipamentos conforme descrito pelos fabricantes de cada um deles. É facilmente verificada porque é visível e segue o princípio da impenetrabilidade da matéria: “Dois corpos distintos não podem ocupar o mesmo lugar no espaço e ao mesmo tempo.” Já um time que trabalha com o conhecimento, essa capacidade não é tangível, pois o estoque do conhecimento está na mente de cada pessoa. Todavia é necessário torná-lo explícito para podermos compreendê-lo e saber qual é o limite do sistema de trabalho.
Olhando para o Fluxo de trabalho, a capacidade de um sistema é dada pelo somatório do Limite de Trabalho em Progresso (WIP Limit) de cada etapa. A ideia é que se olharmos para o quadro e contarmos as opções mais os itens de trabalho, eles não deveriam ultrapassar a capacidade do time.
| Capacidade = ∑ (WIP Limit) |
Occupation Level (Nível de Ocupação)
Esse também não chega a ser uma métrica. É apenas uma ferramenta que relaciona o WIP com a capacidade do sistema. Essa relação demonstra o nível de ocupação do sistema. Se o WIP for igual à Capacidade, dizemos que o sistema está sob stress. Isso significa que se qualquer item urgente chegar (erros, oportunidades emergenciais etc.) o sistema não conseguirá absorver essa demanda.
Caso tentem absorvê-la, o sistema entra em sobrecarga. Há mais trabalho em progresso (WIP) do que a capacidade do sistema.
Geralmente queremos que o sistema esteja em uma folga desejada. Essa se dá pela capacidade menos um valor X que deve ser definido pelo time. Com a folga desejada, consegue-se absorver demandas emergenciais.
Também temos que ter um cuidado para que o sistema não entre em um excesso de folga, pois isso também prejudica o andamento do fluxo. O valor desse excesso de folga deve também ser arbitrado pelo time.
Se não observarmos o excesso de folga, acabaremos deixando o sistema morrer de inanição (starvation). Acontece quando a quantidade de itens acaba ou chega próxima de zero. É o momento em que o time começa a atualizar o LinkedIn, pois acha que em breve não haverá mais nada para fazer.
O ideal é que mantenhamos o sistema com a folga desejada e que em alguns momentos acabemos variando entre o stress e o excesso de folga.
Action Time (Tempo de Ação), Waiting Time (Tempo de Espera), External Dependency Time (Tempo na Dependência Externa) e Blocked Time (Tempo de Bloqueio)
Aqui temos um quarteto de métricas que estão relacionadas.
Action Time
O Action Time (Tempo de Ação), também chamado de Touching Time (Tempo de toque). Ele se refere ao tempo em que o item está em uma etapa de ação no nosso fluxo. Costumeiramente são as colunas nomeadas com verbos no gerúndio: construindo, avaliando, entregando etc. Esse período indica quanto tempo o time efetivamente trabalhou sobre o item.
Waiting Time
O Waiting Time (Tempo de Espera) é o tempo em que o item esteve parado em uma fila aguardando que alguém começasse a trabalhar nele. São as colunas do particípio: construído, avaliado, analisado. Ou então do infinitivo: A Construir, Para Avaliar, Analisar (veja o debate sobre quadro semântico e sistêmico na subseção de Local Cycle Time).
Blocked Time
Entretanto, o que acontece quando eu tenho um item bloqueado em uma coluna de ação. Eu devo movê-lo para uma coluna de espera? Jamais, o seu fluxo de trabalho sempre reflete a sua realidade. O item continua na coluna de ação. Todavia, começamos a contar o Blocked Time (Tempo de Bloqueio). O Action Time para de contar e contamos o tempo de bloqueio até que ele acabe. Quando isso acontecer, volta a contar o Action Time. Outra forma de fazer isso é com a Subtração Action Time = Action Time – Blocked Time.
External Dependency Time
As dependências externas podem ser um caso à parte. Se há visibilidade do que elas estão fazendo, é possível contabilizar o Action Time e Waiting Time. Agora, se não temos visibilidade, será difícil visualizar em qual coluna o item está. Nesse caso, contamos uma métrica especial chamada External Dependency Time (Tempo na Dependência Externa), também chamado de Dependency Time (Tempo na Dependência).
| Action Time = para cada item em uma coluna de ação, data de saída da coluna – data da entrada. Waiting Time = para cada item em uma coluna de espera, data de saída da coluna – data da entrada. Blocked Time = para cada item em uma coluna de ação que esteja bloqueado, data de término do bloqueio – data de início do bloqueio. Dependency Time = para cada item em uma coluna de dependência externa, data de saída da coluna – data da entrada. |
Efficiency Rate (Taxa de Eficiência)
Quão eficiente é o seu fluxo de trabalho? Para saber isso, você pode utilizar uma das funções abaixo. Você pode medir a Taxa de Eficiência de Todo o Fluxo, A Taxa de Eficiência do Upstream ou a Taxa de Eficiência de Midstream e Downstream. É comum que a Taxa de Eficiência do Fluxo esteja próxima a 10% com times que possuem muitas dependências externas, essa eficiência cai para 5% ou menos. Times altamente eficientes, chegam próximos a 20% de eficiência.
O que isso significa? Mesmo que o seu time seja altamente eficiente, 80% do tempo os itens ficarão parados em filas de espera. Aguardando a vez deles entrarem em estágios de ação. Pense nisso na próxima vez que te perguntarem o prazo de algum trabalho.
| Taxa = i i eficiência Fluxo = ∑Action time (todos os entregues) ÷ End-to-End Customer Lead Time x 100 i eficiência Upstream = ∑Action time (apenas no upstream) ÷ Upstream Lead Time x 100 i eficiência Downstream = ∑Action time (apenas no Downstream) ÷ Customer Lead Time x 100 |
Conclusão
No total vimos aqui 4 métricas de Midstream e Downstream, 4 métricas do Upstream e 8 métricas comuns ou que percorrem o Upstream, Midstream e Downstream. Além de 1 restrição e 1 ferramenta de comparação.
É bastante coisa, mas lembre-se do que escrevi no início deste artigo. Jamais tente colocar todas as métricas em prática. Pergunte-se: Qual o problema que eu quero resolver? Dessa resposta derive as métricas para acompanhamento.
Se quiser saber mais, temos o treinamento de KSD, ou Kanban System Design, que pode te ajudar a desenvolver ainda mais processos.
Espero vê-los em breve. Até mais!
* Artigo modificado em 04/08/2023. Em abril de 2023 a Kanban University deixou de utilizar o nome o End-to-End Customer Lead Time (Tempo Ponta a Ponta de Espera do Cliente), conforme definido no livro Essential Upstream Kanban (pp.3, 8, 12-14) para chamar essa métrica apenas como o Customer Lead Time. Veja os porquês dessa mudança no artigo: O Customer Lead Time mudou! Veja aqui a nova definição 
