O que é Sprint?

A Sprint faz parte do Scrum desde sua concepção original, apresentada por Ken Schwaber e Jeff Sutherland em 1995, com o nome inspirado na ideia de um esforço curto e intenso, em contraste com projetos tradicionais de ciclo longo. O termo e o conceito já apareciam nas primeiras versões do Scrum Guide, publicadas a partir de 2010.

A duração máxima de um mês para a Sprint se manteve estável ao longo de todas as revisões do Scrum Guide. O que mudou foi a rigidez em torno do escopo: versões mais antigas do guia falavam em um plano imutável durante a Sprint, enquanto a versão de 2020 é mais explícita ao afirmar que o escopo pode ser esclarecido e renegociado com o Product Owner à medida que mais se aprende, desde que a Meta da Sprint não seja comprometida.

O Scrum Guide 2020 também reforçou a Sprint como um contêiner: todo o trabalho necessário para atingir a Meta do Produto acontece dentro de Sprints, e cada Sprint pode ser vista como um projeto pequeno, com um objetivo próprio.

Pensa na Sprint como um pequeno projeto dentro de um projeto maior: tem início, meio e fim, um objetivo definido, e termina em algo que pode ser mostrado. A diferença é que, ao final, um novo pequeno projeto começa imediatamente, sem intervalo.

Duração. No máximo um mês, o que na prática costuma ser uma, duas ou quatro semanas. Sprints mais longas aumentam o risco: mais coisa pode mudar no mercado ou na tecnologia antes da próxima inspeção. Sprints mais curtas aumentam a frequência de aprendizado, mas cobram mais overhead de planejamento proporcionalmente. A duração escolhida deve se manter estável ao longo do tempo, para criar ritmo previsível.

O que acontece dentro dela. A Sprint começa com a Sprint Planning, na qual o Time Scrum define a Meta da Sprint e seleciona itens do Product Backlog para o Sprint Backlog. Ao longo dos dias, o time se sincroniza na Daily Scrum e refina, em paralelo, os próximos itens do backlog. A Sprint termina com a Sprint Review, em que o time inspeciona o resultado com stakeholders, seguida da Retrospectiva, em que o time inspeciona o próprio processo.

A Meta da Sprint. É o objetivo único que dá coerência aos itens selecionados. Sem ela, a Sprint vira uma lista de tarefas desconexas: cada item poderia ser trocado por qualquer outro sem fazer diferença. Com uma boa Meta da Sprint, fica claro o que faz sentido incluir e o que pode esperar, mesmo que pareça urgente.

Escopo pode ser esclarecido, não substituído. Durante a Sprint, o Product Owner e os Desenvolvedores podem refinar o entendimento sobre os itens já selecionados, à medida que aprendem mais. O que não muda é a Meta da Sprint: se ela deixa de fazer sentido, o Scrum Guide prevê o cancelamento da Sprint pelo Product Owner, uma medida rara, usada só quando o objetivo se tornou obsoleto.

Sem Sprint Zero. Uma confusão comum é tratar a fase inicial de preparação de um projeto, antes da primeira entrega real, como uma "Sprint Zero". O Scrum Guide não reconhece esse conceito: se não há um Incremento inspecionável ao final, não é uma Sprint de verdade, é uma fase de preparação que precede o primeiro ciclo.

A Sprint também pode ser cancelada. O Scrum Guide prevê essa possibilidade, embora raramente aconteça na prática: somente o Product Owner tem autoridade para cancelar uma Sprint, e isso só faz sentido quando a Meta da Sprint se tornou obsoleta, por uma mudança brusca de mercado, de estratégia ou de tecnologia. Cancelar não é o mesmo que trocar o escopo: é encerrar o ciclo inteiro antes do prazo e recomeçar com uma Sprint Planning nova.

Inspecione o objetivo, não só o calendário. A Sprint tem duração fixa, mas o trabalho dentro dela é adaptado à medida que o Time Scrum aprende. Na Daily, os Developers verificam progresso em direção ao Sprint Goal e atualizam o Sprint Backlog. O Product Owner ajuda a esclarecer valor e a negociar escopo quando necessário. Na Sprint Review, o grupo examina o Incremento e mudanças no contexto; na Retrospectiva, melhora a forma de trabalhar. Essa sequência cria oportunidades de decisão, não garantia de que uma previsão inicial estava correta. Se um item deixa de contribuir para a Meta da Sprint, discuta sua prioridade em vez de concluí-lo apenas para manter a lista original. Também não espere o último dia para testar integração ou reunir feedback: Incrementos prontos podem ser entregues antes da Review. Uma Sprint saudável combina foco temporal com flexibilidade de execução e transparência sobre o que foi de fato concluído.

Imagine dois times na mesma empresa de logística.

Time A, cuidando do rastreamento de encomendas, trabalha com Sprints de uma semana. O mercado muda rápido: um concorrente lança um recurso novo, e a empresa quer reagir em dias, não semanas. Toda semana, o time coloca nas mãos dos clientes uma melhoria pequena e utilizável, mede o uso e decide o próximo passo com base no que aprendeu. O planejamento é frequente, mas como os itens são pequenos e bem entendidos, essa reunião dura pouco.

Time B, cuidando da integração com um novo parceiro de transporte internacional, trabalha com Sprints de duas semanas e quer aumentá-las para quatro. O argumento: o trabalho depende de negociações e homologações externas lentas, o planejamento parece repetitivo e, no fim de cada Sprint, quase nada está pronto. Na Retrospectiva, a pergunta que muda a conversa é: que problema uma Sprint maior resolveria? O time percebe que a duração esconderia a causa real, que são itens grandes demais e uma dependência externa tratada só no final. Em vez de esticar a Sprint, o time fatia o trabalho para entregar valor a cada ciclo: começa simulando a interface do parceiro, libera primeiro uma única rota para um grupo pequeno de clientes reais e traz a homologação para dentro da cadência, com o Scrum Master ajudando a remover essa barreira junto ao parceiro. A Sprint continua com duas semanas, e agora cada uma termina com algo utilizável.

Repara na conta: Sprints de uma semana dão 52 ciclos de aprendizado por ano; de quatro semanas, só 13. Aumentar a Sprint reduz experimentos, feedback e capacidade de adaptação, e costuma apenas adiar o problema. Reduzir é o caminho quando o time consegue entregar valor em ciclos menores.

Vale notar também o que nenhum dos dois times fez: escolher a duração copiando outra empresa ou trocá-la na primeira Sprint difícil. A duração pode ser revista de vez em quando, com dados de vários ciclos e motivada por um fato concreto, como uma automação que permite entregar valor mais rápido. Mantê-la estável permite comparar Sprints entre si e enxergar tendências reais nas métricas.

A Sprint é uma iteração, mas nem toda iteração é uma Sprint: o que torna a Sprint específica é o conjunto de regras do Scrum Guide em torno dela, como a duração fixa, a Meta única e os dois eventos obrigatórios de fechamento. Times que usam "Sprint" apenas como sinônimo de "período de trabalho", sem esses elementos, estão, na prática, rodando outra coisa. Isso não é problema de nomenclatura: sem as regras por trás do nome, o time perde justamente os mecanismos que fazem a Sprint funcionar, como o compromisso único da Meta e os dois eventos obrigatórios de fechamento, que existem para garantir que a interação termine em aprendizado, não só em entrega.

Cursos K21 recomendados