Métricas Ágeis comuns ao upstream, midstream e downstream

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

Este post não tem tags.

Compartilhe:

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

Métricas Ágeis: Upstream

 

As Métricas Ágeis comuns ao upstream, midstream e downstream são:

Quadro de mapeamento do fluxo com as seguintes etapas. No Upstream: Piscina de opções (sem limitação e com ícone representando um backlog). Separada por uma linha tracejada. A seguir a etapa de análise com limite de dois itens e com duas colunas: analisando e analisado. Após, Priorização com limite de três itens e as colunas priorizando, priorizado. A linha que separa essas duas colunas marca o ponto de comprometimento. No Midstream temos: Construção, limitada a três itens com as colunas “Construindo” e “Construído”, após a avaliação limitada a quatro itens com as colunas “Avaliando” e “Avaliado”. Em seguida temos o Downstream com uma única etapa não limitada (sinal de infinito). Por fim temos o Entregue com uma bandeira quadriculada de chegada. A separação entre Entrega e Entregue é o ponto de entrega.
Métricas comuns ao Upstream, Midstream e Downstream

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
Fórmula de cálculo do Customer Lead Time 
A descrição do fluxo é a mesma da imagem inicial. Há uma seta que começa após a piscina de opções e para no Ponto de Entrega. Que é justamente o Customer Lead Time
Quadro mapeando o Fluxo de Trabalho demonstrando qual o ponto de início e término da contagem do Customer Lead Time

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
Fórmula de cálculo do Total Aging (Envelhecimento Total)

Aqui mais uma vez cabem todas as recomendações já escritas no Customer Lead Time.

A descrição do fluxo é a mesma da imagem inicial. Há uma seta que começa na piscina de opções e para no Ponto de Entrega. Essa não é uma seta completa, pois ela para e há uma reticência no meio dela.
Total Aging contabiliza desde o surgimento da opção até o dia corrente, caso já tenha sido entregue, será a data da entrega. Nesse caso ele será igual ao 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
Fórmula de cálculo do Local Lead Time (Tempo de Espera Local) Quadro Sistêmico
A descrição do fluxo é a mesma da imagem inicial. Agora há pequenas setas indicando o Lead Time de cada etapa. A análise começa na piscina de opções e termina quando ultrapassa a coluna “Analisando”. Priorização começa na coluna “Analisado” e termina quando ultrapassa a coluna “Priorizando”. A construção começa na coluna “Priorizado” e termina quando ultrapassa a coluna “Construindo”. Avaliação começa na coluna “Construído” e termina quando ultrapassa a coluna “Avaliando”. A entrega começa na coluna “Avaliado” e termina quando ultrapassa a coluna “Entregue”. Também há uma seta começando em priorizado e indo até Avaliado chamada de Lead Time Construção + Avaliação.
Lead Time em um quadro sistêmico.

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
Fórmula de cálculo do Lead Time (Tempo de Espera) Quadro Semântico
O fluxo foi alterado para se adaptar ao quadro semântico. Começa com a piscina de opções. A etapa de análise passou para A Analisar e Analisando. Priorização: Para Priorizar e Priorizando. O Ponto de Comprometimento agora fica entre o Priorizado e Disponível para Construir. A Construção: Disponível para Construir e Construindo. Avaliação: Disponível para Avaliar e Avaliando. Entrega e Entregue continuam iguais. Agora há pequenas setas indicando o Lead Time de cada etapa. Análise começa em A Analisar e termina na coluna após o Analisando. Priorização começa em Para Priorizar e termina na coluna após o Priorizando. A Construção começa em Disponível para Construir e termina na coluna após o Construindo. Avaliação começa em Disponível para Avaliar e termina na coluna após o Avaliando. O Lead Time da Entrega está inteiro na entrada e saída da coluna Entrega. Também há uma seta entre Disponível para Construir até a etapa de Entrega chamada de Lead Time Construção + Avaliação.
Lead Time em um quadro semântico.

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
Fórmula de cálculo da Throughput (Vazão)
A descrição do fluxo é a mesma da imagem inicial. Não há mais setas, apenas um relógio temporizador. Em cada etapa e a quantidade de post-its que chegou em cada etapa na coluna de espera indicando a vazão. São elas: Analisado: Vazão da Análise. Dois itens na semana 1 e dois itens na semana 2. Priorização: Vazão da Priorizado. Um item na semana 1 e um item na semana 2. Construído: Vazão da Construção. Dois itens na semana 2 e dois itens na semana 3. Avaliado: Vazão da Avaliação. Dois itens na semana 7 e dois itens na semana 8.
Quadro mapeando o Fluxo de Trabalho e onde são contabilizadas a vazão das etapas.

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
Fórmula de cálculo do Work in Progress (Trabalho em Progresso)
A descrição do fluxo é a mesma da imagem inicial. Estão espalhados post-its em diferentes áreas. Contam como trabalho em progresso: “Analisando”, duas opções, sendo uma delas bloqueada. “Analisado”, uma opção. “Priorizando”, uma opção. “Priorizado”, dois itens. Construindo, dois itens, sendo um deles bloqueado. Construído dois itens, “Avaliando” está vazio. “Avaliado”, três itens, Entrega com três itens. Há também itens e opções que não contam no WIP. Três opções na piscina de opções. Sete opções descartadas. Quatro itens entregues e três itens abortados.
O Trabalho em Progresso (WIP) no Fluxo de trabalho.

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.

A descrição do fluxo é a mesma da imagem inicial. Apresentado um círculo sobre cada limite de WIP em cada etapa. Análise é igual a 2. Priorização é igual a 3, Construção é igual a três, Avaliação é igual a quatro. Entrega sinalizada na cor vermelha, pois é infinita.
Limitação do Trabalho em Progresso. Cada etapa do Fluxo tem o seu.

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.

A descrição do fluxo é a mesma da imagem inicial. A única diferença desta imagem para a anterior é que são setas saindo do Limite de WIP de cada etapa (4 no total, descontada a entrega) à palavra Capacidade
Capacidade do fluxo é igual ao somatório dos limites de trabalho em progresso (WIP). Nesse caso é igual a 12.
Capacidade = ∑ (WIP Limit)
Fórmula de cálculo da Capacity (Capacidade)

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.

Um sinal vermelho escrito sobrecarga ao lado. Um sinal amarelo, escrito stress do lado. Um sinal verde escrito Folga desejada, um sinal amarelo escrito excesso de folga e outro sinal vermelho escrito: inanição.
Níveis de Ocupação de um sistema de trabalho.

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.
Fórmula de cálculo de Waiting, Action, Dependency e Blocked Time
A descrição do fluxo é a mesma da imagem inicial. Há setas de Aging em Piscina de Opções. Action time em Analisando, Priorizando, Construindo e Avaliando. Waiting Time em Analisado, Priorizado, Construído e Avaliado. Dependency Time na Entrega e um item com bloqueio e Blocked Time em Analisando.
Apresentação das Métricas de Waiting, Action, Dependency e Blocked Time, além do Aging.

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
Fórmula de cálculo de Efficiency Rate

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 
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…