GowDZilla · Delivery Metrics

Como cada métrica é calculada

Um guia de referência do que cada número significa, de onde ele sai no Azure DevOps e o que o faz subir ou descer. Use o índice ao lado para navegar.

Comece por aqui

Conceitos-chave

Duas ideias sustentam todo o resto. Entendê-las faz o restante encaixar.

Data de entrega

A entrega de um item é a data do deploy de produção. Quando não há deploy rastreado, cai para a data de fechamento.

RegraeffectiveDeliveryDate = deployedAt ?? completedAt

A mesma regra vale no painel e na exportação mensal — por isso os dois batem. Tipos ISSUE e OTHER ficam de fora da seleção de entrega.

Incluídos × Ignorados

Todo card clicável abre um detalhamento com duas abas: os itens que entraram no número e os que foram ignorados, cada um com o motivo (ex.: sem committedAt, entrega fora do período).

Os mesmos motivos viram flags acionáveis na tela Itens com problemas, para corrigir o dado na origem.

Vazão

Entrega & Produtividade

Quanto o time entrega e em que ritmo.

Throughput

itens

Quantos itens de trabalho o time efetivamente entregou (colocou em produção ou fechou) dentro do período selecionado.

Por que importaÉ a medida mais direta de vazão do time. Acompanhar a tendência mês a mês mostra se a cadência de entrega está estável, subindo ou caindo — sem depender de estimativa de esforço.

FórmulaContagem de itens entregues no periodo. Entrega = deployedAt ?? completedAt dentro do periodo.

Exemplo12 User Stories com data de entrega em junho → Throughput de junho = 12.

Campos no Azure DevOps: System.WorkItemTypeMicrosoft.VSTS.Common.ClosedDatedeploy (pipeline run)
Exclusões: Tipos ISSUE e OTHER; itens entregues fora do periodo.

Story Points

pontos

Soma dos story points dos itens entregues no período — o throughput ponderado pela complexidade estimada de cada item.

Por que importaComplementa o throughput em contagem: dois meses com o mesmo número de itens podem ter esforço muito diferente. Útil para comparar capacidade entregue, não só quantidade.

FórmulaSoma de storyPoints dos itens entregues no periodo, usando a mesma selecao do Throughput.

ExemploItens entregues em junho somando 5 + 8 + 3 pontos → Story Points de junho = 16.

Campos no Azure DevOps: Microsoft.VSTS.Scheduling.StoryPoints
Exclusões: Tipos ISSUE e OTHER; itens sem entrega no periodo.

Throughput médio

itens

Média de itens entregues por mês e por sprint, considerando todo o histórico carregado — não só o período selecionado no topo.

Por que importaDá uma linha de base de cadência para planejamento e para comparar um período específico contra o comportamento típico do time.

Fórmula

Total de itens entregues no dataset inteiro carregado, dividido pela quantidade de meses distintos com entrega (média/mês) e pela quantidade de sprints distintas com entrega (média/sprint).

Exemplo60 itens entregues em 5 meses com entrega → 12 itens/mês.

Campos no Azure DevOps: System.WorkItemTypeMicrosoft.VSTS.Common.ClosedDateSystem.IterationPath
Exclusões: Tipos ISSUE e OTHER; itens sem entrega. Ignora o filtro de período (mês/sprint) selecionado no topo; respeita apenas o time e os tipos marcados nos chips.

SP médio

pontos

Média de story points entregues por mês e por sprint sobre todo o histórico carregado.

Por que importaLinha de base de capacidade em pontos, para planejamento de sprint e comparação de um período contra o padrão do time.

Fórmula

Soma de storyPoints dos itens entregues no dataset inteiro, dividida pela quantidade de meses distintos com entrega (média/mês) e pela quantidade de sprints distintas com entrega (média/sprint).

Exemplo80 pontos entregues em 4 sprints com entrega → 20 pontos/sprint.

Campos no Azure DevOps: Microsoft.VSTS.Scheduling.StoryPointsSystem.IterationPath
Exclusões: Tipos ISSUE e OTHER; itens sem entrega. Ignora o filtro de período (mês/sprint) selecionado no topo; respeita apenas o time e os tipos marcados nos chips.

Rework

itens

Quantidade de Issues abertas no período. No board, uma Issue representa um ajuste/retrabalho identificado sobre algo já entregue.

Por que importaProxy de retrabalho: muitas Issues indicam que entregas estão voltando para correção. Conta por data de criação (quando o problema apareceu), não por entrega.

Fórmula

Contagem de itens do tipo Issue criados dentro do período selecionado (createdAt), independente de terem sido entregues.

Exemplo7 Issues criadas em junho → Rework de junho = 7, mesmo que ainda estejam abertas.

Campos no Azure DevOps: System.WorkItemTypeSystem.CreatedDate
Exclusões: Só conta tipo Issue. Ignora o filtro de tipos (chips) do topo da página.

Tempo

Tempo de fluxo

Quanto tempo uma demanda leva da ideia à produção.

Lead Time

horas

Tempo médio entre a criação do item e sua entrega. Cobre toda a vida do item, incluindo o tempo parado na fila antes de alguém começar.

Por que importaMede a velocidade de resposta do time à demanda do ponto de vista de quem pediu. Lead Time alto com Cycle Time baixo indica gargalo na fila/priorização, não na execução.

FórmulaMedia de entrega - createdAt. Entrega = deployedAt ?? completedAt.

ExemploItem criado dia 1 e entregue dia 6 → Lead Time = 120h (5 dias).

Campos no Azure DevOps: System.CreatedDateMicrosoft.VSTS.Common.ClosedDatedeploy (pipeline run)
Exclusões: ISSUE e OTHER; itens sem createdAt.

Lead Time for Changes (DORA)

horas

Métrica DORA clássica: tempo entre o início do trabalho (entrada em Active) e o deploy em produção. Diferente do Lead Time de produtividade, não conta o tempo de fila anterior ao início.

Por que importaUma das quatro métricas DORA. Mede a eficiência do fluxo de desenvolvimento até produção. Times elite entregam mudanças em menos de um dia.

FórmulaMédia de deployedAt - committedAt, apenas para itens com committedAt e deployedAt preenchidos.

ExemploItem entrou em Active dia 2 e foi para produção dia 3 → 24h.

Campos no Azure DevOps: Microsoft.VSTS.Common.ActivatedDatedeploy (pipeline run)
Exclusões: ISSUE e OTHER; itens sem committedAt (nunca passaram por Active) ou sem deploy rastreado.

Cycle Time

horas

Tempo médio entre o início efetivo do trabalho (entrada em Active) e a entrega. Exclui o tempo de fila antes do início.

Por que importaMede a eficiência da execução em si. Cycle Time crescente indica itens grandes demais, bloqueios ou trabalho em paralelo em excesso (WIP alto).

FórmulaMedia de entrega - committedAt. committedAt usa ActivatedDate como proxy de entrada em Active.

ExemploItem entrou em Active dia 3 e foi entregue dia 5 → Cycle Time = 48h.

Campos no Azure DevOps: Microsoft.VSTS.Common.ActivatedDateMicrosoft.VSTS.Common.ClosedDatedeploy (pipeline run)
Exclusões: ISSUE e OTHER; itens que nunca passaram por Active (sem ActivatedDate).

DORA

Deploy & Estabilidade

Frequência de entrega em produção e o quanto ela se mantém de pé.

Deployment Frequency

deploys

Quantos deploys de produção o time fez no período. Métrica DORA de frequência de entrega.

Por que importaFrequência alta de deploys, com lotes pequenos, é sinal de fluxo saudável e menor risco por entrega. Times elite fazem deploy sob demanda (múltiplos por dia).

FórmulaNumero de deploys distintos no periodo.

ExemploAgrupamento por dia: 3 dias com deploy de produção no mês → Deployment Frequency = 3.

Campos no Azure DevOps: Pipelines de producao do time (Softex-API/APP-Prd; Diagnostico-API/APP-Prd)run.finishedDaterun.result=succeeded
Exclusões: Runs cancelados ou falhos; deploys antes do DORA_START_DATE (quando configurado; sem ele, todo o lookback conta).

Change Failure Rate

Percentual dos DEPLOYS do período que quebraram produção. Denominador = deploys; numerador = deploys com pelo menos um Bug/Incidente atribuído a eles. Responde: "de cada 10 vezes que subi para produção, quantas quebraram?"

Por que importaMétrica DORA de estabilidade do RELEASE. Olha para o ato de colocar em produção, não para o que foi construído. Times elite ficam abaixo de 15%. Diferença para o Defect Rate: aqui o denominador são deploys e a âncora é o deploy causador; o Defect Rate divide por User Stories e ancora na US causadora. Um deploy que sobe 5 USs e quebra conta como 1 falha no CFR, mas pode gerar vários defeitos no Defect Rate.

FórmulaDeploys com falha / total de deploys no periodo. Falha = Bug ou Incident apontando o deploy causador.

Exemplo5 deploys no mês, 1 com Bug vinculado → CFR = 1/5 = 20%.

Campos no Azure DevOps: System.WorkItemTypeincidentCauseDeploymentNamedeploymentName
Exclusões: Sem deploys no periodo retorna sem valor. Pode ser segmentado por bug, incidente ou ambos.

MTTR

horas

Tempo médio para resolver falhas. Recovery mede do momento em que a falha foi aberta até fechada; Repair mede desde o deploy que a introduziu até o fechamento.

Por que importaMétrica DORA de recuperação. Quanto menor, mais rápido o time restaura o serviço após uma falha. Repair é o mais fiel ao DORA, mas exige rastreio do deploy causador.

Fórmula

Dois cálculos exibidos lado a lado, ambos média de duração:
• Recovery = completedAt - createdAt do Bug/Incident (tempo total do item vivo, do momento em que foi aberto até fechado).
• Repair = completedAt do Bug/Incident - deployedAt do deploy que o causou (tempo desde a causa raiz até restaurar o serviço; ignora diferença negativa). Este é o mais próximo do MTTR clássico do DORA ("time to restore service").

ExemploIncidente aberto e fechado no mesmo dia → Recovery ≈ 8h. Se o deploy causador foi 2 dias antes → Repair ≈ 56h.

Campos no Azure DevOps: System.CreatedDateMicrosoft.VSTS.Common.ClosedDateSystem.WorkItemTypeincidentCauseDeploymentNamedeploy (pipeline run)
Exclusões: Itens que não são Bug ou Incident; falhas não concluídas no período. Repair exige um deploy causador rastreado — sem ele, o item entra em "sem rastreio" e não conta na média de Repair.

Produto

Qualidade

Quanto do que foi construído voltou com defeito.

Defect Rate

Percentual das USER STORIES entregues que geraram defeito. Denominador = USs entregues no período; numerador = falhas vinculadas (via link Related) a essas USs. Responde: "de cada 10 histórias que entreguei, quantas voltaram com bug?"

Por que importaMétrica de qualidade do que foi CONSTRUÍDO, do ponto de vista do produto/história — não do deploy. Diferença para o Change Failure Rate: o CFR divide por deploys e ancora no deploy causador (estabilidade do release); o Defect Rate divide por User Stories e ancora na US causadora (qualidade da entrega). A mesma falha pode entrar nas duas métricas por caminhos diferentes: no CFR pelo deploy que a introduziu, no Defect Rate pela US que a originou.

FórmulaFalhas vinculadas / User Stories entregues no periodo, com deduplicacao por workItemRef.

Exemplo40 USs entregues, 8 com bug vinculado → Defect Rate = 8/40 = 20%.

Campos no Azure DevOps: System.WorkItemTypeSystem.LinkTypes.RelatedincidentCauseWorkItemRef
Exclusões: Sem User Stories entregues retorna sem valor. Bug sem link Related para a US nao entra.

Ponto de confusão comum

CFR × Defect Rate

As duas medem falha, mas respondem perguntas diferentes. A diferença está no denominador e na âncora.

Change Failure Rate

“De cada 10 vezes que subi para produção, quantas quebraram?”

Divide por deploys do período
Âncora deploy causador
Mede estabilidade do release

Defect Rate

“De cada 10 histórias que entreguei, quantas voltaram com bug?”

Divide por User Stories entregues
Âncora US causadora (link Related)
Mede qualidade da construção

Uma mesma falha pode contar nas duas por caminhos diferentes: no CFR pelo deploy que a introduziu, no Defect Rate pela US que a originou. Um deploy que sobe 5 USs e quebra é 1 falha no CFR, mas pode virar vários defeitos no Defect Rate.

Filtros do painel

Critérios de seleção

Estes filtros mudam quais itens e deploys entram no cálculo de todas as métricas.

Período: mês ou sprint

Mês: itens/deploys cuja data de entrega (deployedAt ?? completedAt) cai no mês. Sprint: usa a janela de datas da sprint (start/finish do Azure DevOps) do time selecionado.

Sprint — por data de entrega vs por marcação

Por data de entrega (padrão, alinhado ao projeto Alocações): o item conta na sprint cuja janela de datas contém a data de entrega. Item da Sprint 10 entregue na janela da Sprint 11 conta na 11. Por marcação: o item conta na sprint do seu campo Iteration Path (System.IterationPath), independente de quando foi entregue. Nesse modo, throughput/story points/lead/cycle/defect seguem a marcação, mas os deploys (Deployment Frequency, Change Failure Rate, MTTR Repair) continuam pela janela de datas da sprint — pois deploy não tem Iteration Path.

Deploys — agrupados por dia vs todas as runs

Agrupados por dia (padrão): runs de back e front no mesmo dia UTC contam como 1 deploy. Todas as runs: cada run de produção conta como 1 deploy.

Fonte de falha — bug, incidente ou ambos

Change Failure Rate e Defect Rate são segmentados por fonte. O seletor escolhe se considera apenas Bug, apenas Incidente, ou ambos.

Data de entrega (effectiveDeliveryDate)

Conceito central: a entrega de um item é a data do deploy de produção (deployedAt) quando ele existe; na ausência de deploy rastreado, cai para a data de fechamento (completedAt). A mesma regra vale no painel DORA e na exportação mensal, para que os dois batam.