Posso mudar o tamanho de uma Sprint?

O Roberto Pereira, Product Owner, nos mandou a seguinte dúvida:

O timebox da Sprint pode variar no decorrer do projeto? Exemplo: Sprint1: 2 semanas, Sprint2: 3 semanas, Sprint3: 2 semanas e assim por diante…

Nossa Resposta

Caro Roberto,

Uma Sprint pode mudar de tamanho quando não iniciada, em alguns momentos isso é recomendável mas na maioria das vezes isso é danoso.

É interessante quando o time percebe que não consegue entregar incremento de software no tempo pré-determinado de uma Sprint. Desta maneira, o time aumenta o tamanho da próxima Sprint e segue assim por um bom tempo.

Todavia alterar o tamanho da Sprint possui como trade-offs a perda do referencial de timing e de velocidade de uma Sprint, e demorar mais para se adaptar as mudanças.

A perda de noção de timing de Sprint, ocorre quando o time perde a ideia de quando deve começar a fazer processos importantes dentro de uma Sprint, como quando deve implantar no ambiente de homologação master ou quando deve obter assinaturas que autorizam a subida em produção.

Já a perda de referencial de velocidade ocorre porque ao aumentar o tempo de Sprint em 1/3 não ocorre um aumento na produtividade de 1/3. Na prática a velocidade pode tanto aumentar como diminuir…

Ops, como assim diminuir?

A famosa síndrome de estudante pode atacar o seu time… Ou seja, o seu time pode operar como nos tempos de faculdade no qual deixava para fazer as atividades perto do prazo de entrega.

Aumentar o tamanho da Sprint também significa demorar mais para escutar o PO, e por consequência o software muda de maneira mais lenta. Isso pode ser mais danoso que os dois itens acima juntos.

Para finalizar, no coração do Scrum encontra-se o conceito de trabalhar com timebox… E o seu time deve aprender a trabalhar com uma timebox definida.

Se vocês acordarem que vai ter um incremento de software a cada duas semanas, todos vão ter que gastar massa cinzenta para conseguir este objetivo.

O time de desenvolvimento vai aprender a ser mais objetivo, o que envolve organizar melhor as tarefas, os processos, e a eliminar o desperdício com supérfluos técnicos.

O Product Owner vai aprender a granularidade correta das atividades para caber na Sprint. De início ele vai achar impossível quebrar as tarefas, mas depois de um tempo ele vai conseguir acertar a granularidade.

Não sei por qual motivo você quer mudar, mas agora que já sabe alguns trade-offs, você pode tomar uma decisão bem fundamentada.

Em caso de dúvidas sobre metodologias ágeis mande um sinal de fumaça ou envie sua dúvida por e-mail.