GUIA
Backlog Health: Runway, Aging e Itens Parados
Uma métrica de fluxo sobre o que ainda não está sendo trabalhado — quão grande é o backlog, há quanto tempo cada item está parado, e quantas semanas de trabalho ele representa.
O que mede
Backlog health é na verdade três sinais relacionados sobre tudo que está num estado "ainda não começado". O tamanho do backlog é simplesmente quantos itens estão esperando. O aging quebra essa contagem em faixas por quanto tempo cada item está parado — 0-7 dias, 7-30, 30-90, 90-180 e 180+. O runway divide o tamanho do backlog pelo velocity semanal recente do time, respondendo uma pergunta diferente das outras duas: não "quanto está esperando", mas "quantas semanas de trabalho isso representa, no ritmo que a gente realmente entrega".
Por que importa
Backlog é onde prioridade vai pra ser esquecida. A maioria das conversas de planejamento foca no que está em andamento ou no que foi entregue recentemente, porque é isso que aparece numa daily — o backlog em si raramente é olhado como um todo, e é exatamente por isso que item envelhece lá por meses sem ninguém decidir matar ou promover. O aging transforma esse problema invisível em visível: um pico na faixa de 180+ é um sinal direto e inequívoco de que o backlog parou de ser uma lista priorizada e virou um lugar onde coisa vai morrer.
O runway importa por um motivo diferente — é o número que transforma "a gente tem backlog demais" ou "precisamos planejar mais" numa conversa concreta em vez de um sentimento. Um runway de 40 semanas não é ruim por si só, mas é um fato que vale a pena saber antes de comprometer mais um trimestre de iniciativas novas em cima disso. Também é um dos poucos números de Flow que conecta direto com uma conversa de roadmap: é a resposta honesta pra "se a gente parasse de adicionar qualquer coisa nova hoje, quanto tempo levaria pra dar conta do que já está na lista".
Como calcular
O tamanho do backlog é uma contagem atual de itens num status "não começado". O aging distribui
esses itens por tempo desde a criação, em faixas fixas — deliberadamente não configuráveis, pra
gráficos continuarem comparáveis ao longo do tempo e entre times. Um item parado
(stale) é aquele que não foi atualizado (qualquer mudança de campo, não só troca de
status) há mais que um limite — 30 dias é um padrão comum, mas o número certo depende de quão
ativamente o backlog de um time é organizado. Runway é tamanho do backlog ÷ velocity médio
semanal num período recente — se o velocity for 0 (nada concluído recentemente), runway não
é um número que faça sentido e não deveria ser mostrado como se fosse.
Como interpretar os números
Não existe benchmark de mercado publicado pro "tamanho certo de backlog" ou pro "runway certo" — depende inteiramente do tamanho do time, de quão à frente o time planeja, e de como o backlog é usado (uma fila de trabalho ativa vs. um depósito de ideias de longo prazo são coisas bem diferentes usando o mesmo rótulo). O que é útil independente do time: a forma da distribuição de aging. Um backlog saudável pende pras faixas mais novas, com as mais antigas ficando menores — os itens ou são trabalhados ou são fechados. Um backlog que pende pra velho, com uma faixa de 180+ crescendo, geralmente significa que a entrada de item está passando da triagem, não que o time está atrasado na execução.
Uma armadilha comum
O instinto quando um backlog parece doente é agendar uma faxina grande — mas um backlog que está envelhecendo há 6 meses geralmente continua sem prioridade pelo mesmo motivo de novo: ninguém é dono da decisão de fechar item que não importa mais. Um hábito de triagem recorrente e leve (mesmo que sejam 15 minutos por semana olhando especificamente a faixa mais antiga) costuma funcionar melhor que uma faxina ocasional grande, porque pega os itens enquanto o contexto de "a gente ainda precisa disso" ainda está fresco.
Como o moasy.tech calcula isso
O moasy.tech acompanha tamanho do backlog, as 5 faixas de aging, uma contagem de item parado (com limite configurável) e runway automaticamente a partir do que já é sincronizado do Jira e Linear — sem planilha manual de "o que está parado há tempo demais". Deliberadamente sem prioridade, esforço ou story points embutidos — esses campos não existem de forma consistente em todo provider, então backlog health continua sendo um sinal factual (contagem, idade, ritmo), não um opinativo.
Veja as outras métricas de fluxo no guia completo, ou a implementação completa na página de Flow Metrics.
Dado ilustrativo, apenas para demonstração.
Perguntas sobre backlog health
O que conta como "não começado" pro tamanho do backlog?
Qualquer item num status que as regras de workflow do seu time classificam como backlog — configurável por time, já que a configuração de board varia, com um padrão da empresa como fallback.
Por que prioridade ou story points não fazem parte disso?
Esses campos não são consistentes entre Jira, Linear e todo outro provider — alguns times usam rigorosamente, outros não usam nada. Backlog health se atém a fatos que toda integração consegue de fato fornecer: quantos itens, quão velhos, e quão rápido o time está dando vazão a eles.
Um runway longo é sempre um problema?
Não necessariamente — um time que deliberadamente planeja vários trimestres à frente vai ter um runway mais longo que um que só organiza algumas semanas adiante. O que vale a pena observar é a tendência: um runway que continua crescendo significa que o backlog está passando da capacidade real do time de dar conta dele.
Veja seu próprio backlog health
Começar grátis