A maioria dos líderes de engenharia se surpreende ao descobrir que o código fica esperando revisão por mais tempo do que levou para ser escrito. O PR cycle time mede exatamente isso: o tempo total decorrido desde a abertura de um pull request até o merge. Quando esse número é alto, seu pipeline de entrega desacelera, o squad carrega contexto por mais tempo do que o necessário e os compromissos do sprint escorregam. Esta página cobre a definição, como medir, benchmarks do setor, como melhorar e como o DevStats expõe esses dados automaticamente.
Principais conclusões
- O PR cycle time mede o tempo decorrido entre a abertura de um pull request e o merge. É um dos sinais mais claros de quão eficientemente seu squad move o código do "escrito" para o "entregue", e uma entrada direta na velocidade geral de entrega do time.
- O PR cycle time é calculado assim: hora do merge menos hora de abertura do PR. Times de engenharia de elite atingem consistentemente um PR cycle time mediano abaixo de 24 horas, segundo a pesquisa DORA State of DevOps. Qualquer valor acima de 3 dias sinaliza um gargalo relevante no seu processo de revisão.
- O erro mais comum dos times é tratar um PR cycle time alto como um problema de pessoas, e não de processo. Cycle times longos quase sempre têm origem no tamanho do PR, na atribuição indefinida de revisores ou na falta de capacidade de revisão, não no esforço individual de cada player.
- O DevStats rastreia o PR cycle time automaticamente ao se conectar ao seu provedor Git, com detalhamentos por squad, tamanho do PR e etapa de revisão, comparados a mais de 1.000 times de engenharia. Comece um trial gratuito e veja seus números em menos de dois minutos.
Definição de PR cycle time
O PR cycle time é o tempo total que um pull request fica aberto antes do merge. Começa quando o PR é criado e termina quando ele é mergeado na branch de destino. Essa métrica captura o ciclo completo de revisão e iteração, incluindo o tempo aguardando um revisor, o tempo gasto endereçando feedback e o tempo em qualquer fila de aprovação.
A fórmula é direta: PR cycle time = timestamp do merge menos timestamp da abertura. Na prática, você quer olhar para a mediana de todos os PRs em um período, não para a média, porque alguns PRs muito grandes ou bloqueados distorcem bastante a média. Quando o PR cycle time é alto, ele atrasa diretamente o throughput do time e comprime o tempo disponível para testes e deployment antes que uma janela de release se feche.
Por que o PR cycle time importa para times de engenharia
Quando os squads não rastreiam o PR cycle time, revisões lentas ficam invisíveis. Um player termina uma feature, abre um PR e fica esperando. Essa espera raramente aparece na retrospectiva do sprint porque não se manifesta como uma tarefa. Ela se acumula silenciosamente, e quando o sprint perde o alvo, a causa raiz está enterrada sob uma semana de trocas de contexto e branches desatualizadas.
O PR cycle time se conecta diretamente aos KPIs pelos quais líderes de engenharia são medidos: entrega no prazo, cadência de releases e satisfação dos desenvolvedores. Players que esperam dias por revisões relatam menor engajamento e gastam mais tempo se reorientando ao próprio código quando o feedback finalmente chega. Times que rastreiam o PR cycle time no DevStats recebem um detalhamento por etapa de revisão, para que o líder veja se o atraso está na primeira revisão, na iteração ou na aprovação final. Essa distinção muda completamente a intervenção necessária.
O PR cycle time é um componente direto da métrica DORA de "lead time for changes", que mede o tempo do commit até a produção. Medir é o primeiro passo. O engineering manager é quem decide o que mudar.
Como medir o PR cycle time
Para calcular o PR cycle time, você precisa de dados com timestamp do seu provedor Git: especificamente, o horário de criação e o horário de merge de cada pull request. GitHub, GitLab e Bitbucket expõem isso via API. Você calcula o tempo decorrido para cada PR e depois tira a mediana na janela de tempo escolhida, normalmente um sprint de duas semanas ou um período móvel de 30 dias.
Segmentações úteis incluem tamanho do PR (linhas alteradas), squad, repositório e autor. O tamanho importa porque um PR de 1.500 linhas naturalmente leva mais tempo para revisar do que um de 50 linhas. Comparar cycle time sem controlar o tamanho pode levar a conclusões erradas. Você encontra contexto baseado em pares nos benchmarks do DevStats, que mostram como os números do seu time se comparam a organizações de engenharia similares.
Nenhum padrão publicado define os níveis de PR cycle time da mesma forma que o DORA define a frequência de deployment, mas os dados do setor a partir da pesquisa DORA e de plataformas de analytics de engenharia oferecem uma referência direcional consistente. Os benchmarks variam por tamanho de time, complexidade do codebase e modelo de release.
| Nível de desempenho | Benchmark de PR cycle time | O que sinaliza |
|---|---|---|
| Elite | Menos de 24 horas | Revisões rápidas, PRs pequenos, ownership claro |
| Alto | 1 a 3 dias | Processo saudável com atrasos ocasionais de revisão |
| Médio | 3 a 7 dias | Capacidade de revisão limitada ou PRs grandes demais |
| Baixo | Mais de 7 dias | Gargalo significativo; risco de entrega é alto |
PR cycle time na prática: um exemplo real
Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que a velocidade dos sprints vinha caindo por dois trimestres consecutivos, mesmo sem o squad reportar problemas de capacidade. Ela puxou os dados de PR cycle time e descobriu que a mediana havia subido de 1,8 dias para 5,4 dias ao longo de seis meses. Os dados mostravam que o atraso estava concentrado na segunda etapa de revisão, depois que o primeiro round de feedback era endereçado. Os revisores não voltavam para uma segunda passagem dentro de um prazo razoável.
Ela fez uma única mudança de processo: estabeleceu uma norma explícita de que o retorno na segunda revisão deveria acontecer em até quatro horas úteis, e tornou as atribuições de revisão explícitas em vez de deixá-las para voluntários. Três sprints depois, o PR cycle time mediano havia caído para 2,1 dias e a taxa de conclusão de sprint do squad se recuperou. Ela acompanhou a mudança usando o PR cycle time junto com os dados de code review para confirmar que o padrão se mantinha entre revisores e repositórios diferentes.
Como melhorar o PR cycle time
- Reduza o tamanho dos PRs. Defina uma norma de time para o máximo de linhas alteradas por PR, normalmente entre 200 e 400 linhas. PRs menores são mais rápidos de revisar, mais fáceis de entender e menos propensos a ficarem parados, porque a carga cognitiva sobre o revisor é menor. Acompanhe o tamanho mediano dos PRs junto com o cycle time como um indicador antecedente.
- Atribua revisores explicitamente na criação do PR. PRs sem atribuição esperam significativamente mais do que os atribuídos. Incorpore esse hábito no seu template de PR ou automatize com um arquivo CODEOWNERS. Se você vê cycle time alto concentrado em repositórios específicos, a atribuição de revisores costuma ser o primeiro lugar para investigar.
- Defina um SLA de revisão e torne-o visível. Uma norma compartilhada, como primeira revisão em até quatro horas durante o horário de trabalho, elimina ambiguidade. Publique-a no acordo de trabalho do time. Use os dados do activity heatmap para entender quando seu squad está mais ativo e alinhe as janelas de revisão a esse ritmo.
- Rastreie o tempo de espera de revisão separadamente do tempo de iteração. Se o gargalo está na primeira resposta de um revisor, é um problema de capacidade ou priorização. Se está na iteração após o feedback, pode indicar comentários de revisão pouco claros ou change requests grandes demais. O DevStats expõe o detalhamento do PR cycle time por etapa, para que você direcione a intervenção certa para a etapa certa.
- Conecte o PR cycle time ao issue cycle time. Um PR cycle time rápido que ainda produz um issue cycle time lento aponta para gargalos upstream no planejamento ou no escopo. Melhorar só a velocidade de revisão não move o ponteiro se as issues estiverem mal definidas antes do trabalho começar.
PR cycle time vs. lead time for changes
O PR cycle time e o lead time for changes são relacionados, mas medem períodos diferentes do seu processo de entrega. O lead time for changes, uma das quatro DORA metrics centrais, mede a jornada completa do commit até o deployment em produção. O PR cycle time é um subconjunto dessa jornada, cobrindo apenas a fase de revisão e merge.
| PR cycle time | Lead time for changes | |
|---|---|---|
| Mede | Tempo em revisão e merge | Tempo do commit até a produção |
| Começa quando | O PR é aberto | O primeiro commit é feito |
| Termina quando | O PR é mergeado | O código chega à produção |
| Melhor para | Diagnosticar gargalos de revisão | Desempenho de entrega end-to-end |
Use o PR cycle time quando quiser isolar especificamente o processo de revisão. Use o lead time for changes quando precisar reportar o desempenho geral de entrega para stakeholders ou fazer benchmark contra os níveis DORA.