Sprint iniciado não se mexe

Iniciando a série perguntas e respostas, dúvida na lista scrum-brasil:

2008/7/29 Alguém wrote:
Olá pessoal,

Gostaria de tirar algumas dúvidas:

Imaginem que existe um sprint definido e iniciado, que possui 10 tarefas. Depois de passados alguns dias, o Product Owner quer trocar um item do Sprint por outro de mesmo peso, que ainda não foi iniciado. Isso poderia ser feito? Ou em Sprint iniciado não se mexe?

Essa é uma pergunta muito comum nos cursos que ministro. Na maioria das vezes não é simplesmente trocar um pelo outro. Muitas vezes o planning é um momento onde aprofundamos em requisitos, fazemos alguns modelos rascunhando, levantamos tarefas, preparamos o que for necessário e isso sempre é sobre as Stories que selecionamos para o Sprint.

Durante o Sprint é o único momento onde o escopo está fixo (escopo do Sprint). Isso faz parte do contrato Scrum. Isso garante o mínimo de segurança para a equipe trabalhar num terreno um pouco mais firme mesmo que por um curto prazo. Sou partidário do “sprint iniciado não se mexe”. Já tive cliente que o Product Owner queria toda hora mudar o Sprint Backlog. Isso gerava um estresse grande na equipe. A equipe não sabia o dia de amanhã. É muito ruim.

Um artifício que o Product Owner pode usar é cancelar o Sprint, mas isso significa parar o Sprint atual e voltar para o Planning. Não é uma coisa muito comum e nem muito agradável. O Product Owner tem que se organizar!

Segunda pergunta: se o Product Owner quiser tocar um item do sprint que ainda não foi iniciado, por outro de peso maior, o que consequentemente iria aumentar o tamanho do sprint, isso poderia ser feito? Estou considerando que o Product Owner tem consciência que essa alteração irá aumentar o tamanho do sprint e ele não se importa se o sprint tiver 1 semana a mais, se for necessário.

Antes de mais nada, leia isso aqui:

http://gc.blog.br/2008/05/05/nao-da-pra-fazer-so-mais-uma-coisinha/

O Product Owner está no comando do barco num processo Scrum. Ele está guiando o desenvolvimento. Ele tem muito controle sobre a equipe, mas esse controle é ordenado e as regras do contrato Scrum devem prevalecer sempre. O ScrumMaster não pode deixar o Product Owner fazer o que quiser.

Já disse que não é uma boa idéia mexer no escopo do Sprint corrente. E para todos os efeitos, vocês da scrum-brasil vão ficar de castigo. Escrevam 100 vezes na lousa:

ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!
ITERAÇÃO É TAMANHO FIXO!

O timebox é um conceito sagrado. Iterações tem tamanho fixo e todas são do mesmo tamanho. Costumo dizer para as equipes: “- Este Sprint termina na data 01/04/20XX. Quer vocês queiram, quer vocês não queiram, ele vai terminar nessa data.”

Essa regra não é uma rigidez conceitual qualquer. É só para deixar as coisas mais simples. Desenvolvimento iterativo possui um conjunto mínimo de regras que faz o processo funcionar. Abrir mão de algumas delas gera muita confusão.