O que é sprint no Scrum: duração, regras e ciclo completo
Para entender o que é sprint no Scrum, pense numa pergunta que todo patrocinador faz: "quando eu vejo alguma coisa funcionando?". A Sprint é a resposta do framework. É um ciclo de duração fixa, de no máximo um mês, no qual o time transforma uma parte das ideias do backlog em algo que pode ser usado, mostra o resultado e decide o próximo passo com o que aprendeu.
O Guia do Scrum 2020 chama as Sprints de coração do Scrum, o lugar onde ideias viram valor. Todo o trabalho acontece dentro delas, inclusive os outros quatro eventos: Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective. Por isso a Sprint não é uma reunião nem uma fase do projeto. Ela é o contêiner que dá ritmo a todo o resto.
A palavra vem do atletismo, onde sprint é uma corrida curta em velocidade máxima. A analogia engana um pouco: no Scrum, a ideia não é correr até a exaustão, e sim manter um ritmo que o time sustente indefinidamente, Sprint após Sprint.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é sprint no Scrum, segundo o Guia
O Guia define as Sprints como eventos de duração fixa, de um mês ou menos, para criar consistência. Três frases do texto explicam quase tudo:
- Uma nova Sprint começa imediatamente após o fim da anterior. Não há semana de descanso, de testes ou de planejamento entre elas.
- Todo o trabalho necessário para atingir a Meta do Produto acontece dentro das Sprints. Planejamento, execução, revisão e melhoria fazem parte do ciclo.
- Cada Sprint pode ser considerada um projeto curto. Ela tem objetivo, plano, execução e entrega, em escala pequena.
O objetivo de cada Sprint é a Meta da Sprint, criada pelo Scrum Team na Sprint Planning. É ela que dá foco ao time e permite flexibilidade no detalhe: os itens escolhidos podem mudar, desde que a meta continue sendo perseguida.
Quanto dura uma sprint e como escolher
O limite é um mês. Dentro dele, o time escolhe. Na prática, duas semanas é uma escolha frequente, mas não é regra. O que o Guia pede é consistência: escolhida a duração, ela se mantém, para que o time aprenda quanto consegue fazer em um ciclo e para que as partes interessadas saibam quando haverá Sprint Review.
O próprio Guia explica o raciocínio: quando o horizonte da Sprint é longo demais, a meta pode perder a validade, a complexidade cresce e o risco aumenta. Sprints mais curtas geram mais ciclos de aprendizado e limitam o custo de errar. Para escolher, considere:
| Fator | Favorece Sprints mais curtas (1 a 2 semanas) | Favorece Sprints mais longas (3 a 4 semanas) |
|---|---|---|
| Incerteza do produto | Alta: precisa de feedback frequente | Menor: direção mais estável |
| Disponibilidade das partes interessadas | Conseguem participar de revisões frequentes | Só conseguem participar uma vez por mês |
| Tamanho dos itens | Itens já divididos em partes pequenas | Itens que dificilmente cabem em poucos dias |
| Custo dos eventos | Time acostumado, eventos enxutos | Time novo, eventos ainda pesados |
Mudar a duração de vez em quando, depois de uma Retrospectiva, é aceitável. Mudar a cada Sprint para "caber" o trabalho é sinal de que o problema está no tamanho dos itens, não no calendário. Os limites de tempo de cada evento dentro da Sprint estão explicados no artigo sobre timebox no Scrum.
As regras que valem durante a Sprint
O Guia lista quatro regras para o período da Sprint. Elas são curtas e resolvem a maior parte das brigas de corredor:
- Nada que coloque em risco a Meta da Sprint entra. O pedido urgente do diretor pode entrar se não ameaçar a meta. Se ameaçar, vai para o backlog e será considerado na próxima Planning.
- A qualidade não diminui. Cortar testes para "fechar a Sprint" não é opção. O que não atende à Definição de Pronto não faz parte do Incremento.
- O Product Backlog é refinado conforme necessário. O time continua preparando os próximos itens enquanto trabalha nos atuais.
- O escopo pode ser esclarecido e renegociado com o Product Owner. Conforme o time aprende, alguns itens podem sair ou mudar, sempre em conversa com o PO e preservando a meta.
Repare na diferença entre a regra 1 e a regra 4: a meta é estável; o caminho até ela, não.
Quando a sprint pode ser cancelada
Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta, por exemplo, quando a empresa desiste do produto ou uma mudança de regulamentação torna o objetivo inútil. Só o Product Owner tem autoridade para cancelar. Cancelamento é raro e deve continuar raro: se acontece com frequência, as metas estão sendo definidas sem a informação necessária.
Como funciona o ciclo completo da Sprint
O ciclo tem sempre a mesma sequência. O calendário abaixo é um exemplo ilustrativo de uma Sprint de duas semanas em um projeto de implantação de sistema, com eventos dimensionados proporcionalmente aos limites do Guia:
| Momento | Evento | O que sai dele |
|---|---|---|
| Dia 1, manhã | Sprint Planning (cerca de 4 horas) | Meta da Sprint, itens escolhidos e plano inicial |
| Dias 1 a 10 | Daily Scrum, 15 minutos por dia | Plano do dia ajustado rumo à meta |
| Ao longo da Sprint | Refinamento do backlog (atividade, não evento) | Próximos itens claros e menores |
| Dia 10, início da tarde | Sprint Review (cerca de 2 horas) | Resultado inspecionado e backlog ajustado |
| Dia 10, fim da tarde | Sprint Retrospective (cerca de 1h30) | Melhorias para a próxima Sprint |
| Dia 11 | Nova Sprint Planning | Começa a Sprint seguinte |
Cada evento alimenta o próximo. A Planning parte do backlog ordenado (veja o que é backlog na metodologia ágil); a Daily adapta o plano da Planning; a Review mostra o resultado e muda o backlog; a Retrospectiva melhora a forma de trabalhar. O artigo sobre como conduzir a Sprint Planning detalha a abertura do ciclo, e o roteiro de Sprint Review mostra como fechar a parte de produto com as partes interessadas.
O Incremento não precisa esperar o fim
Um detalhe que muita gente desconhece: o Guia permite entregar Incrementos às partes interessadas antes do fim da Sprint. A Sprint Review não é um portão de aprovação para liberar valor. Se uma funcionalidade fica pronta no quinto dia e pode ir para produção, ela pode ir.
Sprint em projetos fora do software
O conceito funciona sempre que o trabalho tem incerteza e dá para gerar um resultado utilizável em poucas semanas. Alguns exemplos ilustrativos:
- Marketing: cada Sprint lança uma peça de campanha e mede a resposta antes de produzir a seguinte.
- Evento corporativo: as primeiras Sprints validam formato, local e programação com a diretoria, em vez de fechar tudo no início.
- Projeto em órgão público: um serviço digital é liberado por etapas para um grupo pequeno de cidadãos, e cada Sprint incorpora o que foi aprendido.
O cuidado é não chamar de Sprint um período de duas semanas com lista de tarefas. Sem Meta da Sprint, sem resultado inspecionável e sem Review com quem usa, o que existe é um cronograma fatiado.
Erros comuns com a Sprint
- Sprint de "estabilização" ou de testes. Se o Incremento precisa de uma Sprint só para ficar pronto, a Definição de Pronto está fraca.
- Esticar a Sprint para terminar o que faltou. O que não ficou pronto volta para o Product Backlog. A data de fim não se move.
- Sprint sem meta, só com lista de itens. O time perde o critério para decidir o que fazer quando surge um imprevisto.
- Eventos pulados quando o prazo aperta. Sem Review e Retrospectiva, a Sprint vira só um prazo de entrega.
O que fazer agora
Pegue o calendário da sua próxima Sprint e confira três pontos: a duração é a mesma da anterior, a Meta da Sprint está escrita numa frase que qualquer pessoa entende e a Review está marcada com quem vai usar o resultado. Se algum faltar, corrija antes da Planning. Para situar a Sprint entre os outros conceitos ágeis, veja o guia completo de métodos ágeis e Scrum. E, se quiser dominar o framework inteiro com método, o curso Agile Scrum Foundation da Projeto Diário cobre eventos, papéis e artefatos com preparação para o exame de certificação.
