Postagens

Duração do sprint: seus sprints devem ser de 1, 2, 3 ou 4 semanas?

Um espaço de trabalho de um time ágil mostrando um quadro branco com calendário com blocos de sprint marcados em diferentes cores para várias durações de sprint

Matt Lewandowski

Última atualização 16/02/20269 min de leitura

Escolher uma duração de sprint parece uma pequena decisão até você perceber que ela molda como seu time planeja, estima, reflete e entrega. Toda cerimônia de Scrum escala com a duração do sprint, o que significa que sua escolha tem efeito cascata em todo o processo de desenvolvimento. A maioria dos times opta por padrão por duas semanas sem pensar. Isso funciona bem para muitos, mas não é a única opção, e nem sempre é a melhor. Aqui está como escolher a duração de sprint que realmente se encaixa no seu time.

O que o Guia de Scrum diz

O Guia de Scrum estabelece uma regra: sprints são um mês ou menos. Isso é tudo. Sem duração mínima, sem padrão recomendado, apenas um teto. Na prática, a indústria convergiu para sprints de duas semanas. Aproximadamente 58% dos times os usam, de acordo com o relatório State of Agile. Mas essa popularidade não os torna universalmente corretos. Sprints de uma semana e de quatro semanas têm cada um casos de uso legítimos, e sprints de três semanas funcionam silenciosamente bem para certas estruturas de time.

58%

dos times executam sprints de 2 semanas

4 weeks

duração máxima do sprint de acordo com o Guia de Scrum

~20%

do tempo do sprint tipicamente perdido para sobrecarga

Comparando durações de sprint

Cada duração de sprint cria um equilíbrio diferente entre velocidade de feedback e tempo de execução. Aqui está como eles se comparam.

Sprints de 1 semana

Aspecto	Detalhe
Melhor para	Startups, projetos urgentes, times com requisitos que mudam rapidamente
Velocidade de feedback	Muito rápido, você aprende algo novo toda semana
Sobrecarga de cerimônia	Alta, aproximadamente 20-25% do sprint são reuniões
Esforço de planejamento	Menor por sprint, mas você planeja quatro vezes por mês
Risco	Baixo, apenas uma semana de trabalho em risco se as prioridades mudarem

Sprints de uma semana forçam priorização extrema. Você só pode acomodar um punhado de itens, o que significa que o time precisa ser implacável sobre o que importa mais. O planejamento do sprint é curto (máximo duas horas), mas acontece toda semana. Esse ritmo funciona quando requisitos mudam frequentemente, quando você está explorando o ajuste produto-mercado, ou quando o time precisa de loops de feedback apertados para permanecer alinhado com stakeholders. Ele desmorona quando itens de trabalho são inerentemente grandes ou quando o time gasta mais tempo em cerimônias do que construindo.

Sprints de 2 semanas

Aspecto	Detalhe
Melhor para	A maioria dos times, o padrão da indústria por uma boa razão
Velocidade de feedback	Balanceada, rápida o suficiente para a maioria das necessidades dos stakeholders
Sobrecarga de cerimônia	Moderada, aproximadamente 12-15% do sprint são reuniões
Esforço de planejamento	Gerenciável, duas vezes por mês
Risco	Baixo a moderado, duas semanas de trabalho em risco

Sprints de duas semanas acertam o ponto ideal para a maioria das organizações. Há tempo suficiente para completar trabalho significativo, mas o ciclo de feedback ainda é curto o suficiente para detectar problemas cedo. O refinamento do backlog acontece uma ou duas vezes por sprint, e o time tem tempo para absorver novas informações entre cerimônias. Este é o padrão por uma razão. Se você não tem certeza por onde começar, comece aqui.

Sprints de 3 semanas

Aspecto	Detalhe
Melhor para	Times com dependências pesadas ou trabalho de integração complexo
Velocidade de feedback	Mais lenta, mas suficiente para produtos estáveis
Sobrecarga de cerimônia	Menor, aproximadamente 10-12% do sprint são reuniões
Esforço de planejamento	Menos frequente, mas as sessões são mais longas
Risco	Moderado, três semanas de trabalho poderiam errar

Sprints de três semanas são incomuns, o que faz alguns times evitá-los. Mas eles resolvem um problema real: quando duas semanas não são suficientes para completar e integrar features significativas, mas quatro semanas criam muita deriva do feedback dos stakeholders. Times com dependências complexas entre múltiplos serviços ou times frequentemente acabam aqui naturalmente. A semana extra dá espaço para respirar para integração e testes sem estender os horizontes de planejamento muito longe.

Sprints de 4 semanas

Aspecto	Detalhe
Melhor para	Times maduros com produtos estáveis e trabalho previsível
Velocidade de feedback	Lenta, um mês inteiro entre check-ins dos stakeholders
Sobrecarga de cerimônia	Percentual mais baixo, aproximadamente 8-10% do sprint
Esforço de planejamento	Uma vez por mês, mas sessões de planejamento são mais longas (até 8 horas)
Risco	Maior, um mês inteiro de trabalho pode precisar de retrabalho

Sprints de quatro semanas minimizam a sobrecarga de cerimônia como porcentagem do tempo total. O time recebe mais tempo de construção ininterrupto, mas o loop de feedback é mais longo. Se o time vai na direção errada, leva um mês para corrigir o rumo. Isso funciona melhor para times maduros construindo produtos estáveis onde requisitos não mudam frequentemente. Falha quando stakeholders precisam de visibilidade regular ou quando o mercado se move mais rápido que seu ciclo de sprint.

Um time colaborando em uma sala de conferência com uma tela mostrando um gráfico de barras comparando a sobrecarga de cerimônia entre diferentes durações de sprint

O cálculo da sobrecarga de cerimônia

Aqui está uma pergunta que a maioria dos times nunca faz: que percentual do seu sprint é realmente gasto em reuniões? Scrum prescreve cinco eventos, cada um com timeboxes que escalam com a duração do sprint. Vamos calcular a sobrecarga de cerimônia para um time de sete pessoas trabalhando 40 horas por semana.

Cerimônia	Sprint de 1 semana	Sprint de 2 semanas	Sprint de 3 semanas	Sprint de 4 semanas
Planejamento do Sprint	2 h	4 h	6 h	8 h
Standup Diário	1,25 h	2,5 h	3,75 h	5 h
Revisão do Sprint	1 h	2 h	3 h	4 h
Retrospectiva	0,75 h	1,5 h	2,25 h	3 h
Refinamento	2 h	4 h	6 h	8 h
Horas totais de cerimônia	7 h	14 h	21 h	28 h
Horas disponíveis	40 h	80 h	120 h	160 h
Sobrecarga %	17,5%	17,5%	17,5%	17,5%

Os percentuais são aproximadamente iguais quando você segue os timeboxes proporcionais do Guia de Scrum. Mas aqui está o que a matemática não mostra: custos de mudança de contexto. Sprints mais curtos significam transições mais frequentes entre "modo cerimônia" e "modo construção". Times em sprints de uma semana frequentemente relatam que a sobrecarga se sente muito mais alta do que os números sugerem porque as cerimônias estão agrupadas perto uma da outra. Na prática, muitos times que executam sprints de uma semana não escalam suas cerimônias proporcionalmente. Uma retrospectiva que leva 90 minutos em um sprint de duas semanas raramente cai para 45 minutos em um sprint de uma semana. É aí que a verdadeira diferença de sobrecarga aparece.

Não otimize cerimônias a zero

Alguns times tentam reduzir a sobrecarga pulando cerimônias. Isso dá errado. Pular retrospectivas significa que problemas de processo se intensificam. Pular refinamento significa que o planejamento do sprint leva três vezes mais tempo. As cerimônias existem por uma razão.

Fatores de decisão

Escolher uma duração de sprint não é apenas matemática. Esses são os fatores que realmente importam.

Maturidade do time

Times novos em agile se beneficiam de sprints mais curtos porque recebem mais prática com as cerimônias. Times experientes podem lidar com sprints mais longos porque internalizaram a disciplina.

Cadência de release

Se você deploya continuamente, a duração do sprint é menos ligada ao deployment. Se releases acontecem nos limites do sprint, sprints mais curtos significam releases mais frequentes e feedback mais rápido dos usuários.

Necessidades dos stakeholders

Alguns stakeholders precisam de visibilidade semanal. Outros estão bem com check-ins mensais. Sua duração de sprint deve corresponder à frequência de feedback que sua organização exige.

Volatilidade de requisitos

Quando requisitos mudam frequentemente, sprints mais curtos reduzem trabalho desperdiçado. Quando requisitos são estáveis, sprints mais longos permitem que o time se concentre sem replanejar constantemente.

Outros fatores a considerar

Tamanho dos itens de trabalho. Se a maioria das user stories leva 3-5 dias para completar, sprints de uma semana deixam quase nenhuma margem de erro. Sprints de duas ou três semanas oferecem mais flexibilidade. Use Planning Poker durante refinamento para estimar itens e ver como eles se encaixam em diferentes durações de sprint. Tamanho do time. Times maiores (7-9 pessoas) geram mais sobrecarga de coordenação. Sprints mais longos podem absorver esse custo melhor. Times menores (3-5 pessoas) podem se mover rápido com sprints mais curtos. Complexidade da Definição de Pronto. Se sua Definição de Pronto inclui testes pesados, revisões de segurança ou verificações de conformidade, esses processos precisam de tempo. Um sprint de uma semana pode não acomodar gates de qualidade completos.

Um close-up do notebook de um Scrum Master mostrando uma matriz de decisão desenhada à mão comparando diferentes opções de cadência de sprint

Você pode mudar a duração do sprint?

Sim. E você deveria se sua cadência atual não está funcionando. O melhor momento para mudar a duração do sprint é em uma retrospectiva onde o time identifica cadência como causa raiz dos problemas. Sinais comuns de que você precisa de uma mudança:

O time consistentemente não consegue terminar trabalho significativo dentro do sprint

Stakeholders reclamam sobre visibilidade ou frequência de feedback

Cerimônias parecem apressadas ou inchadas em relação à duração do sprint

Objetivos do sprint parecem ou muito vagos (sprint muito longo) ou muito estreitos (sprint muito curto)

Velocidade é errática porque itens de trabalho não se encaixam no tamanho do sprint

Como fazer a transição

Discuta em uma retrospectiva

Use a retro para expor por que a duração atual do sprint não está funcionando. Colete exemplos específicos, não apenas sentimentos. Se o time regularmente leva 40% do trabalho para o próximo sprint, esse é um ponto de dados que vale a pena examinar.

Tente a nova duração por 3-4 sprints

Um sprint não é suficiente para julgar. O primeiro sprint em uma nova duração vai parecer desconfortável porque o time ainda está se calibrando. Dê a ele pelo menos três iterações antes de decidir.

Ajuste durações de cerimônias proporcionalmente

Se você está mudando de sprints de duas semanas para sprints de uma semana, corte pela metade seus timeboxes de cerimônia. Não deixe uma retro de duas horas se espremendo em um sprint de uma semana.

Recalibre a velocidade

A velocidade do sprint não se transfere diretamente entre durações de sprint. Rastreie sua velocidade na nova cadência e dê ao time três sprints para estabelecer uma nova linha de base. Use um gerador de objetivo de sprint para manter objetivos apropriadamente escopo para a nova duração.

Avalie e decida

Após o período de teste, faça uma retro focada na mudança de duração do sprint. Compare previsibilidade de entrega, satisfação do time e feedback dos stakeholders entre a cadência antiga e nova.

Comece mais curto, depois estenda

Se você não tem certeza, comece com sprints de uma semana ou duas semanas. É mais fácil estender uma duração de sprint quando o time está pronto do que encurtar uma quando as coisas não estão funcionando. Sprints mais curtos constroem memória muscular ágil mais rápido.

Um framework de decisão rápido

Se você quer um ponto de partida simples, use este:

Escolha sprints de 1 semana se...

Você é uma startup ou time pequeno, requisitos mudam semanalmente, você precisa do loop de feedback mais rápido possível, ou o time é novo em agile e precisa de prática frequente com as cerimônias.

Escolha sprints de 2 semanas se...

Você não tem certeza o que escolher, seu time é de tamanho médio (5-7 pessoas), você quer um equilíbrio entre velocidade de feedback e tempo de execução, ou está trabalhando em um ambiente típico de desenvolvimento de produto.

Escolha sprints de 3 semanas se...

Seu trabalho envolve dependências entre times pesadas, testes de integração levam tempo significativo, duas semanas consistentemente se sente muito apertado mas quatro semanas se sente como muita deriva.

Escolha sprints de 4 semanas se...

Seu time é experiente com Scrum, requisitos são estáveis, você quer sobrecarga de cerimônia mínima, ou o produto é maturo com um ritmo de desenvolvimento previsível.

Qualquer que seja sua escolha, lembre-se que a duração do sprint é uma variável, não uma constante. Os melhores times revisitam essa decisão periodicamente e se ajustam com base no que aprendem.

Duas semanas é de longe a mais comum. Aproximadamente 58% dos times ágeis usam sprints de duas semanas de acordo com pesquisas da indústria. Sprints de uma semana são os segundos mais comuns, seguidos por sprints de três e quatro semanas.

Sim, e frequentemente deveriam. Um time de plataforma trabalhando em infraestrutura estável pode se beneficiar de sprints de três ou quatro semanas, enquanto um time de produto respondendo ao feedback do mercado pode precisar de sprints de uma ou duas semanas. A restrição chave é coordenação: se times precisam sincronizar frequentemente, limites de sprint alinhados reduzem fricção.

Mudar a duração do sprint reseta sua linha de base de velocidade. Um time que completa 30 pontos de história em um sprint de duas semanas não necessariamente completará 60 em um sprint de quatro semanas porque sobrecarga, mudança de contexto, e precisão de planejamento todos mudam. Rastreie velocidade fresca na nova duração usando uma calculadora de velocidade e permita três sprints para uma linha de base confiável.

Não necessariamente. Muitos times fazem deploy continuamente independentemente da duração do sprint. O sprint é uma cadência de planejamento, não uma cadência de release. Porém, se sua organização exigir releases formais nos limites do sprint, sprints mais curtos significam releases mais frequentes e feedback mais rápido dos usuários.