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. Sprints curtas permitem replanejar quase toda semana, sem esperar um ciclo de um mês para incorporar uma mudança de direção. O custo é um planejamento mais 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 quatro semanas. O trabalho depende de negociações externas lentas, testes de integração complexos e homologação regulatória, processos que não mudam de direção de uma semana para outra. Sprints curtas geraram, no passado, um planejamento quase idêntico Sprint após Sprint, só reconfirmando o mesmo plano, sem ganho real de flexibilidade. A mudança para quatro semanas reduziu o overhead sem perder capacidade de reagir, porque a natureza do trabalho já era mais estável.

Um terceiro sinal ajuda a decidir: quantas vezes, numa Sprint típica, o Product Owner precisa renegociar algo com o time antes do fim do ciclo? Se isso acontece quase toda Sprint, a duração provavelmente está longa demais para o ritmo real do trabalho. Se quase nunca acontece e o planejamento parece repetitivo, vale testar um ciclo mais longo antes de assumir que a causa é outra.

Os dois times fazem a coisa certa, porque escolheram a duração pelo ritmo real de mudança do próprio trabalho, não por um padrão copiado de outro lugar. E os dois mantêm a duração escolhida por vários ciclos seguidos, o que permite comparar Sprints entre si e enxergar tendências de verdade nas métricas.

Vale notar o que os dois times não fizeram: nenhum deles escolheu a duração olhando para o que outra empresa faz, nem trocou de duração na primeira Sprint difícil. A duração de uma Sprint é uma decisão que vale a pena revisar de vez em quando, mas raramente, e sempre com dados de vários ciclos como base, nunca com a frustração de uma única Sprint que deu errado.

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