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.

Este post tem 4 comentários

  1. Pretty! This was an incredibly wonderful post. Thanks for providing this info.

  2. I just like the valuable information you provide on your articles.
    I’ll bookmark your blog and test again right here frequently.
    I’m relatively certain I will be informed a lot of new stuff proper
    here! Best of luck for the next!

  3. Excellent article! We are linking to this great post on our website.
    Keep up the great writing.

Deixe uma resposta