Carryover work

A maioria dos squads subestima o quanto de carryover work acumula até que uma sprint review torna impossível ignorar. Carryover work é qualquer trabalho planejado que não foi concluído dentro do sprint em que estava originalmente programado e passa para o próximo ciclo. Quando acontece ocasionalmente, é uma nota de rodapé de planejamento. Quando acontece em todo sprint, sinaliza um problema sistêmico no seu processo de entrega. Esta página cobre a definição, como medir, como são os benchmarks, como reduzir e como o DevStats mostra esses dados nos seus squads.

Principais conclusões

• Carryover work é qualquer item planejado no sprint que não chega ao estado de concluído até o fim do sprint em que foi comprometido. Isso importa porque carryover repetido corrói a confiabilidade das previsões, frustra stakeholders e mascara a capacidade real e o fluxo dos seus squads de engenharia.
• A taxa de carryover é calculada como o número de itens incompletos do sprint dividido pelo total de compromissos do sprint, expressa em porcentagem. Uma taxa de carryover consistentemente acima de 20% é um sinal que vale investigar, embora os benchmarks variem por tamanho do time, duração do sprint e o quão rigorosamente "concluído" é definido.
• O erro mais comum dos times é tratar o carryover como um custo normal do negócio e nunca examinar a causa raiz. Carryover é um sintoma, não um problema em si. A causa subjacente pode ser scope creep, complexidade subestimada, dependências bloqueadas ou um gargalo de revisão no processo de code review.
• O DevStats rastreia o carryover por sprint automaticamente conectando ao seu issue tracker, com benchmarks contra mais de 1.000 times de engenharia. Você pode ver sua taxa de carryover detalhada por squad e sprint na funcionalidade de sprints. Comece um teste gratuito para ver seus números em menos de dois minutos.

Definição de carryover work

Carryover work é qualquer compromisso de sprint que não é concluído até o fim do sprint em que foi planejado e é movido para um sprint subsequente ou backlog. É uma medida direta de com que precisão um squad executa seu próprio plano dentro de uma janela de tempo fixa.

Tecnicamente, a taxa de carryover é calculada assim: Taxa de Carryover = (Itens incompletos do sprint / Total de compromissos do sprint) × 100. As fontes de dados incluem seu issue tracker (Jira, Linear, GitHub Issues) e a configuração do sprint board. Quando o carryover se acumula ao longo dos sprints, ele se transforma em uma lacuna de confiabilidade que corrói a credibilidade com stakeholders de produto e negócio, tornando mais difícil comprometer datas de roadmap com qualquer credibilidade. Times que usam dados de planning accuracy junto com a taxa de carryover têm uma visão mais clara de onde o processo de estimativa está falhando.

Por que o carryover work importa para times de engenharia

Quando os squads não rastreiam o carryover work, as consequências são invisíveis até que se acumulem. Stakeholders enxergam metas de sprint não atingidas como um problema de confiabilidade. Engineering managers enxergam como um problema de velocidade. Os players do squad frequentemente vivenciam como um problema de troca de contexto, carregando trabalho pela metade entre sprints enquanto absorvem novos compromissos por cima. Nenhuma dessas perspectivas está errada, mas nenhuma delas por si só aponta para a solução.

O carryover afeta diretamente sua capacidade de prever datas de entrega, bater metas trimestrais de roadmap e manter um ritmo sustentável para o seu squad. Taxas altas de carryover também são um indicador antecipado de burnout: os players acumulam uma pilha crescente de trabalho em andamento que nunca fecha completamente. No SPACE framework, o carryover toca satisfação, performance e eficiência ao mesmo tempo, tornando-o um dos sinais de processo mais reveladores disponíveis para um líder de engenharia. Revisar seus dados de throughput junto com a taxa de carryover dá uma leitura mais precisa sobre se o squad está entregando menos trabalho ou apenas comprometendo mais do que consegue absorver.

Medir é o ponto de partida, não a resposta. Quando você sabe sua taxa de carryover e de onde ela vem, está em posição de decidir o que mudar.

Como medir o carryover work

Para calcular a taxa de carryover, conte todas as issues, stories ou tarefas que foram adicionadas a um sprint e não foram marcadas como concluídas até o fechamento do sprint, depois divida pelo total de compromissos do sprint. Multiplique por 100 para expressar como porcentagem. Seu issue tracker é a fonte de dados principal. Para que isso seja significativo, o squad precisa de uma definição consistente de "concluído" e de disciplina para não ajustar retroativamente o escopo do sprint depois que ele termina.

Não existe um único benchmark publicado para taxa de carryover da forma como os DORA metrics existem para frequência de deployment. O que segue é um framework qualitativo baseado em padrões observados em times de engenharia, e os benchmarks variam por tamanho do time, duração do sprint e complexidade do codebase. Você pode comparar a taxa de carryover do seu squad com a de outros times usando os benchmarks do DevStats.

Observação: essas faixas são guias qualitativos, não padrões publicados. Times com ciclos de sprint mais curtos ou trabalho de alta incerteza podem ter carryover naturalmente mais alto. O contexto sempre importa ao interpretar o número.

Carryover work na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que seus squads reportavam consistentemente 30–40% de carryover em três sprints consecutivos. As sprint reviews pareciam bem na superfície: os times estavam ocupados, PRs estavam sendo mergeados e ninguém levantava bloqueios nas standups. Quando ela puxou os dados, descobriu que uma parcela desproporcional dos itens de carryover eram stories que tinham entrado em code review nos dois últimos dias do sprint e nunca foram aprovadas antes do fechamento. O gargalo não era capacidade. Era latência de revisão.

Ela estabeleceu uma norma para o squad: qualquer story em revisão até o dia oito de um sprint de dez dias é priorizada pelo próximo revisor disponível antes de pegar trabalho novo. Ela rastreou o PR cycle time e a taxa de carryover juntos ao longo do mês seguinte. O carryover caiu de 35% para 14%, e a previsibilidade do sprint do squad melhorou o suficiente para o time de produto voltar a confiar nas previsões. Os dados revelaram o padrão. Ela tomou a decisão.

Como reduzir o carryover work

1. Limite os compromissos do sprint a 80% da capacidade histórica. A maioria dos squads se compromete demais porque planeja com base na velocidade média, sem considerar interrupções, revisões e reuniões. Use os dados de throughput dos seus últimos seis sprints para definir um teto realista. Fique atento à resistência imediata de stakeholders que querem mais comprometido por sprint: essa conversa vale ser feita explicitamente.
2. Quebre as stories até que nenhum item único ultrapasse dois dias de trabalho. Stories grandes são a fonte mais comum de carryover. Se uma story não pode ser concluída em dois dias, quase certamente está subespecificada ou ampla demais. Itens menores também tornam os bloqueios visíveis mais rápido, para você agir antes do fim do sprint.
3. Trate a latência de revisão como um sinal de saúde do sprint de primeira classe. Se os itens estão concluindo o desenvolvimento mas travando na revisão, sua taxa de carryover reflete uma lacuna de processo, não de capacidade. Monitore o issue cycle time por estágio para identificar onde os itens estão parados. Estabeleça um acordo no squad sobre o tempo máximo de espera para revisão.
4. Faça uma verificação no meio do sprint sobre os itens em andamento. No dia cinco de um sprint de dez dias, qualquer item que ainda não está em desenvolvimento ativo corre risco de passar para o próximo sprint. Uma triagem de cinco minutos no meio do sprint, sem ser uma reunião completa, dá ao engineering manager a chance de remover do escopo ou reatribuir antes que vire uma falha do sprint.
5. Audite sua definição de "concluído". O carryover às vezes dispara quando os critérios para fechar uma story mudam no meio do sprint. Concorde com os critérios de "concluído" no sprint planning e não os mude durante o sprint. Definições inconsistentes inflam os números de carryover e tornam os dados de tendência não confiáveis.

Carryover work vs. sprint spillover

Carryover work e sprint spillover são frequentemente usados como sinônimos, mas descrevem coisas ligeiramente diferentes. Carryover se refere a itens que foram planejados em um sprint e não foram concluídos, enquanto spillover às vezes descreve especificamente o trabalho que estava em andamento no fim do sprint e continua ativamente no próximo, diferente do trabalho que simplesmente não foi iniciado.

Use a taxa de carryover quando quiser avaliar a confiabilidade dos compromissos de sprint do seu squad. Use o rastreamento de spillover quando quiser entender a continuidade de WIP e o fluxo entre os limites dos sprints. Os dois sinais juntos dão uma visão mais completa da saúde do sprint, que você pode revisar junto com seus dados de sprints no DevStats.