A maioria dos líderes de engenharia descobre que o squad tem um problema de planejamento só depois que um prazo escorrega. O sprint completion rate dá esse sinal antes: ele mede o percentual do trabalho comprometido no sprint que o time realmente entrega até o fim do sprint. Quando esse número é consistentemente baixo, indica um desalinhamento entre capacidade e compromisso, não apenas azar. Esta página cobre a definição, como calcular, o que é um bom resultado e como melhorar.
Key takeaways
- O sprint completion rate mede o percentual do trabalho comprometido no sprint que um squad entrega até o fim do sprint. Uma taxa consistentemente baixa indica que o processo de planejamento está quebrado, não o esforço do time.
- A fórmula é: sprint completion rate = (stories ou pontos concluídos ÷ stories ou pontos comprometidos) × 100. Não existe um DORA benchmark publicado para essa métrica específica, mas a maioria dos squads de alta performance fica consistentemente entre 80% e 90%. Qualquer resultado abaixo de 70% justifica uma revisão de processo.
- O erro mais comum é tratar o sprint completion rate como medida de performance individual. Ele reflete a precisão do planejamento e a saúde do processo em todo o squad, não a entrega de nenhum player específico.
- O DevStats rastreia o sprint completion rate automaticamente conectando ao seu issue tracker, com benchmarks contra mais de 1.000 times de engenharia para você ver onde seu squad está. Comece um teste gratuito e veja seus números em menos de dois minutos.
Definição de sprint completion rate
Sprint completion rate é o percentual de itens de trabalho planejados que um squad conclui dentro de um único sprint. Ele responde a uma pergunta: o time entregou o que disse que entregaria? A fórmula é simples: sprint completion rate = (stories ou pontos concluídos ÷ stories ou pontos comprometidos) × 100.
A métrica usa dados do seu issue tracker, geralmente Jira, Linear ou GitHub Issues, comparando o escopo comprometido no início do sprint com o que chega ao estado "concluído" no fechamento do sprint. Acompanhar isso ao longo do tempo conecta diretamente a um resultado de negócio: entregas previsíveis. Quando os stakeholders confiam nos compromissos do squad, o planejamento de releases e as conversas sobre roadmap ficam muito menos dolorosos. O DevStats expõe esses dados pela sua funcionalidade de sprints, dando aos líderes de engenharia uma visão consistente de compromisso versus entrega em cada sprint.
Por que o sprint completion rate importa para times de engenharia
Squads que nunca medem o sprint completion rate costumam descobrir o problema de planejamento pelos sintomas, não pelos dados: um product manager frustrado com compromissos não cumpridos, um roadmap que continua escorregando ou um time que se sente perpetuamente atrasado mesmo trabalhando muito. Quando esses sintomas aparecem, o padrão geralmente já tem meses. Acompanhar o completion rate expõe o gap entre o que é comprometido e o que é entregue, antes que vire um problema com stakeholders.
Para líderes de engenharia, essa métrica conecta diretamente à entrega no prazo e à confiança dos stakeholders. Um squad que conclui 60% dos compromissos do sprint está, na prática, operando com um processo de planejamento que superestima a capacidade em 40%. Esse gap se acumula: trabalho carrega para o próximo sprint, prioridades conflitam e os players acabam fazendo context-switching entre itens inacabados de vários sprints. Revisar os dados de planning accuracy junto com o sprint completion rate dá o quadro completo de onde os compromissos quebram. Você também consegue ver como a saúde do sprint se conecta a sinais mais amplos de entrega rastreados pelas DORA metrics, que medem frequência de deployment, taxa de falha em mudanças e tempo de recuperação no nível do pipeline.
O sprint completion rate está dentro das dimensões de "performance" e "efficiency" do SPACE framework. Ele mede a saúde do processo, não o esforço individual. Os dados dizem onde olhar; o líder de engenharia decide o que mudar.
Como medir o sprint completion rate
Para calcular o sprint completion rate, divida o número de stories (ou story points) marcados como concluídos no fechamento do sprint pelo número comprometido no início do sprint, depois multiplique por 100. Use o estado que o time define como "concluído" e aplique essa definição de forma consistente. Mudanças de escopo no meio do sprint complicam o cálculo: trabalho adicionado depois do primeiro dia deve ser rastreado separadamente para você distinguir problemas de planejamento de scope creep. Seu issue tracker é a fonte de dados principal. Nenhum dado do Git é necessário para essa métrica, mas combiná-la com dados de throughput do seu provedor Git adiciona uma verificação cruzada útil para confirmar se as stories concluídas viraram código entregue.
Não existe um benchmark publicado e autoritativo para sprint completion rate da mesma forma que existem DORA benchmarks para frequência de deployment. Os intervalos abaixo refletem padrões observados em times ágeis e devem ser interpretados no contexto do tamanho do time, duração do sprint e tipo de trabalho. A funcionalidade de benchmarks do DevStats permite comparar a taxa do seu squad com times de tamanho e estrutura similares.
| Nível de performance | Benchmark de sprint completion rate | O que indica |
|---|---|---|
| Elite | 90–100% | Estimativas precisas, escopo estável e processo de planejamento bem calibrado |
| Alto | 80–89% | Planejamento sólido com surpresas ocasionais de escopo ou capacidade |
| Médio | 70–79% | Overcommitment consistente ou blockers recorrentes que merecem investigação |
| Baixo | Abaixo de 70% | Quebra sistêmica no planejamento: estimativas, controle de escopo ou alocação de capacidade precisam de revisão |
Sprint completion rate na prática: um exemplo real
Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que seus três squads de produto estavam concluindo cerca de 65% dos compromissos do sprint ao longo de seis sprints consecutivos. O trabalho não estava desaparecendo: estava sendo carregado para o sprint seguinte, criando um backlog crescente de features pela metade. Ela puxou os dados de sprint e descobriu que um squad estava adicionando escopo consistentemente no meio do sprint, enquanto um segundo squad estava comprometendo trabalho com dependências não resolvidas no início do sprint. A taxa do terceiro squad melhorou significativamente depois que ela estabeleceu uma regra: nenhum item novo entra no sprint depois do segundo dia sem remover um item equivalente.
Ela mediu o resultado no trimestre seguinte acompanhando tanto o sprint completion rate quanto o issue cycle time, observando se os itens que entravam no sprint também avançavam para concluído mais rápido. Em dois sprints, o controle de escopo baseado em regras levou a taxa do primeiro squad de 63% para 84%. O problema de dependências no segundo squad levou mais tempo para resolver, exigindo mudanças em como os tickets eram refinados antes do sprint planning, mas os dados tornaram a causa raiz visível de uma forma que o feeling nunca conseguiu.
Como melhorar o sprint completion rate
- Limite o escopo do sprint a 80% da capacidade medida. A maioria dos squads faz overcommit porque planeja com base na capacidade teórica, não no throughput histórico real. Puxe a média de pontos concluídos pelo squad nos últimos quatro sprints e use isso como teto de capacidade. Essa mudança isolada tende a ter o impacto mais rápido na taxa de conclusão.
- Congele o escopo depois do segundo dia do sprint. Adições no meio do sprint são uma das causas mais comuns de taxas baixas. Estabeleça uma norma no time: trabalho adicionado depois do segundo dia espera o próximo sprint ou substitui algo já comprometido. Acompanhe a frequência de mudança de escopo como indicador antecedente.
- Resolva dependências antes do início do sprint. Itens que entram no sprint com dependências externas não resolvidas são compromissos de alto risco. Durante o refinamento do backlog, marque qualquer ticket que dependa de outro squad ou serviço externo. Use os dados de collaboration para identificar onde dependências entre squads estão causando atrasos consistentes.
- Revise os itens de carryover como um sinal separado. Trabalho que passa de sprint para sprint merece ser categorizado. É sempre o mesmo tipo de trabalho? São sempre os itens do mesmo membro do squad? Padrões no carryover apontam para problemas de estimativa, gaps de habilidade em uma área específica ou interrupções recorrentes. A funcionalidade de sprints do DevStats expõe os dados de carryover para você identificar esses padrões sem rastreamento manual.
- Combine o sprint completion rate com o PR cycle time. Um squad que conclui 90% das stories do sprint mas com um PR cycle time de cinco dias ou mais pode estar fechando tickets antes que o código seja revisado e mergeado. Use as duas métricas juntas para confirmar que "concluído" no seu issue tracker corresponde a "concluído" no seu pipeline de entrega.
Sprint completion rate vs. velocity
Sprint completion rate e velocity são relacionados, mas medem coisas diferentes: o completion rate mede a confiabilidade dos seus compromissos, enquanto a velocity mede o volume de trabalho que o squad entrega ao longo do tempo.
| Sprint completion rate | Velocity | |
|---|---|---|
| Mede | Percentual do trabalho comprometido que foi concluído | Total de story points concluídos por sprint |
| Começa quando | O compromisso do sprint é definido | O sprint começa |
| Termina quando | O sprint fecha | O sprint fecha |
| Melhor para | Diagnosticar precisão de planejamento e controle de escopo | Prever capacidade futura e prazos de release |
Use o sprint completion rate para avaliar a saúde do processo de planejamento e a velocity para alinhar expectativas com stakeholders sobre o que o squad consegue entregar em um determinado período. As duas métricas ficam disponíveis na funcionalidade de sprints do DevStats para você revisá-las lado a lado.