O que é Sprint?
A Sprint é um evento que contém todos os demais eventos do Scrum: Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
A Sprint é o coração do Scrum, além de executar os eventos citados, é ao final dela que um incremento "Pronto" é criado num estado que chamamos potencialmente lançável.
Seu prazo máximo (time-box) é de 1 mês ou menos e uma nova Sprint começa logo após o final da anterior. Por essa razão a manutenção do seu tamanho é fundamental para trazer cadência e previsibilidade de entrega, uma vez que dessa forma o time vai aprendendo sobre o quanto trabalho é possível ser entregue durante aquele espaço de tempo.
Por que as Sprints tem um prazo curto?
Imagine que a entrega de um produto dure cerca de 6 meses sem que os envolvidos (stakeholders) tenham sido convidados nesse período para uma demonstração. Eles teriam pouca ou nenhuma visibilidade da evolução do produto, certo? Além da falta de visibilidade, Sprints muito longas devem ser evitadas por outras razões:
- Tendem a mudar seu objetivo reduzindo o foco do time naquilo que é importante ser entregue além de aumentar a complexidade e o risco - à medida que torna o planejamento mais imprevisível;
- Atrasam o feedback do cliente e adaptação rápida do time - feedbacks rápidos promovem inspeção e adaptação mais frequentes que possibilitam ao time entregar algo mais alinhado ao cliente, fundamental quando estamos tratando de ambientes complexos;
- Reduz a motivação do time por não trazer um senso de progresso (dado pelas entregas parciais de cada Sprint) e completude. Entregas frequentes proporcionam isso e mantêm a motivação do time elevada.
Tamanho da Sprint
Tamanhos constantes de Sprint reduzem a complexidade da gestão de uma forma geral, pois os stakeholders já esperam ter uma Sprint Review a cada X semanas, o time consegue ser mais assertivo no plano de trabalho e uma release pode ser melhor planejada uma vez que todos saberão quantas Sprints caberão nela.
Vamos supor que o Time esteja trabalhando em Sprints de 2 semanas e a próxima release do produto seja daqui a 3 meses. Logo, essa Release terá 6 sprints, 6 oportunidades de inspeção que proporcionará que o incremento esteja mais próximo do esperado pelos stakeholders.
Por vezes o time pode entender que é necessário modificar o tamanho da Sprint, mas isso deve ser feito entre as Sprints, nunca em seu decorrer. Algumas possíveis razões para modificar o tamanho da Sprint são:
- O tempo não é suficiente para termos um incremento pronto ao final do prazo;
- Eventos externos ao time como feriados, períodos de freezing, funcionários entrando de férias, são motivos que o time pode decidir por aumentar o tamanho da Sprint;
- Condições de mercado e necessidade de atender tais mudanças - "time-to-market";
- Nível de incerteza sobre a tecnologia utilizada;
- Reduzir o tempo de feedback com o cliente - o time de desenvolvimento necessita de feedback do PO e dos Stakeholders de modo a garantir que estão sendo eficientes e eficazes;
O que fazer quando o time alcançar o Objetivo da Sprint antes do seu final?
Caso o time finalize o Sprint Backlog e atinja o objetivo antes do final da Sprint NÃO é correto reduzir o tempo da Sprint. Existem algumas alternativas como aproveitar esse tempo restante para corrigir bugs, refatorar o produto, realizar mais refinamentos, ações de team building, dar folga ou, o mais comum é, adiantar novos itens do Product Backlog.
E quando o time não conseguir executar todo o Sprint Backlog previsto?
Caso o time perceba que não conseguirá alcançar o objetivo, a Sprint não deve ter seu tamanho aumentado para caber os itens restantes e deverá ser encerrada mesmo que o objetivo não seja alcançado ou que restem itens de backlog a serem finalizados. Nesse caso o time deve discutir na Retrospectiva os possíveis motivos e melhorar seu planejamento.
Todos os itens incompletos devem voltar para o Backlog do Produto e podem ser replanejados para Sprint seguinte, dada a prioridade do Product Owner.
Objetivo da Sprint
O Objetivo da Sprint é muito importante para dar propósito a Sprint e trazer foco ao Time, pois sua finalidade compreende um valor de negócio em que o time vai trabalhar, por essa razão a Sprint não deve sofrer mudanças que ponham em risco o objetivo acordado.
Caso o Objetivo da Sprint se torne obsoleto, seja por mudança de tecnologia, mudança de direcionamento da organização, mudança de mercado ou qualquer outro motivo, a Sprint pode ser cancelada, contudo, apenas o PO pode fazê-lo, mas o Time de Desenvolvimento e o Scrum Master podem influenciá-lo nessa tomada de decisão.
Conclusão
A Sprint é um ciclo de desenvolvimento que tem por missão entregar um incremento “Pronto” de produto que seja potencialmente lançável. É um evento container onde acontecem todos os demais eventos do Scrum e deve ter um Objetivo que é responsável por dar propósito e foco ao trabalho executado pelo time. Toda Sprint é oportunidade para que os Stakeholders e o Time Scrum inspecionem o produto (O QUÊ é feito) e para que o time inspecione e adapte a si e seu processo de trabalho (COMO é feito).