Postagens

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

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.

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.

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.

Fatores de decisão

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

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.

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:

Como fazer a transição

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Um framework de decisão rápido

Se você quer um ponto de partida simples, use este: 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.