você está aqui: Home  → Coluna do Cesar Brod

De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.


Scrum - cancelar ou não um Sprint

Por Cesar Brod

Data de Publicação: 13 de Fevereiro de 2015

Em um artigo recente para o portal Scrum Alliance, Deepak Joshi fala sobre o cancelamento de um Sprint e quem deve solicitá-la. Joshi vai atrás do que disseram os gurus do Scrum:

Se o Sprint prova-se inviável, o Scrummaster pode terminá-lo e iniciar um novo por meio de uma nova reunião de planejamento. O Scrummaster pode tomar essa decisão por si, de acordo com a equipe ou em função de solicitação da própria equipe ou do Product Owner. - Ken Schwaber (Agile Project Management with Scrum) @@ @@ Caso o objetivo do Sprint torne-se completamente inválido, a equipe Scrum pode decidir que seguir adiante com ele não faz nenhum sentido e, assim, sugere que o Product Owner o cancele. - Kenneth Rubin (Essential Scrum) @@ @@ Consideremos o caso em que o Product Owner descubra requisitos novos e importantes que devam ser tratados imediatamente, ao invés daqueles com os quais a equipe está envolvida. Algumas vezes isso pode acontecer. Quando isso acontece, sugiro que seja dada a devida visibilidade à mudança do objetivo. Nesse caso, a equipe anuncia o cancelamento do Sprint. - Mike Cohn (Succeeding with Agile)

Joshi ressalta que é importante ter clareza do contexto no qual o Sprint é cancelado e que a equipe Scrum é composta também do Scrummaster e do Product Owner e, por isso, a decisão deve ser consensual.

Ninguém gosta do cancelamento de um Sprint, mas quando o Burndown Chart começa a dar sinais prematuros de que as historias previstas no Backlog não serão entregues, o melhor é jogar às claras, entender que o planejamento foi mal feito, salvar o que pode ser salvo e refazer o planejamento iniciando, imediatamente, um novo Sprint. O que eu recomendo é que, em Sprints com a duração de uma semana, caso o cancelamento aconteça antes da quarta-feira, que seja iniciado um novo mini-sprint com os dias restantes. Caso o cancelamento ocorra depois da quarta, o Sprint que iniciaria na semana seguinte ganha os dias restantes da semana do cancelamento. Isso deve ser uma exceção e é importante lembrar que o ritmo, o pulso do Scrum, deve ser minimamente prejudicado. Nada de ficar mudando as datas de início e fim dos Sprints seguintes.

O cancelamento do Sprint é melhor do que entregar histórias inconclusas ao Product Owner no final do mesmo. A honestidade deve prevalecer sempre. Por outro lado, frequentes cancelamentos de Sprint constituem um mau cheiro, um sinal de que nosso planejamento é fraco, de que o Product Owner não esta comunicando a visão ideal do produto ou de que o Sprint não está devidamente blindado.

Saiba mais

Acompanhamento de projetos com o Google Drive - o terceiro vídeo da série mostra como construir um Burndown Chart

Sobre o autor

Cesar Brod usa Linux desde antes do kernel atingir a versão 1.0. Dissemina o uso (e usa) métodos ágeis antes deles ganharem esse nome. Ainda assim, não está extinto! Escritor, consultor, pai e avô, tem como seu princípio fundamental a liberdade ampla, total e irrestrita, em especial a do conhecimento.

Mais sobre o Cesar Brod: [ Linkedin ] | [ Twitter ] | [ Tumblr ].

Veja a relação completa dos artigos de Cesar Brod