Série Scrum: definindo as histórias para o Sprint

Olá, pessoal! Hoje eu vou explicar pra vocês como é que a equipe define quais histórias estarão no Sprint Backlog do Sprint. Já vimos que o PO é alguém importante no planejamento do Sprint. Então chegou a hora de discutir de como tirar as coisas que estão no Product Backlog e trazer para nossa “mesa”.

Como a equipe define as histórias que vão para um Sprint?

Essa é uma pergunta clássica. Eu já ouvi alguns comentários que talvez o PO, ou SM, deveria fazer isso. Eu acho que se Scrum fosse um framework que funcionasse com base do "quem tem o nível mais alto (para não dizer cargo) é quem define as coisas", talvez faria sentido. Mas como não é assim, o conceito de time, equipe, pessoas, etc, é de fato mais importante que os papéis apenas. 

Enfim, apesar do PO ter escrito toda história e em alguns casos ser o responsável pelo investimento no projeto, no Scrum isso não dá o direito de dizer: “a história já está escrita, priorizada e o escopo é aquele. Se não entendeu algum ponto, por favor, deixe-me saber, mas não vou mudar o escopo, porque eu quero assim”. Não é bem por ai...  A prioridade aqui é o time, ou seja, todos estão envolvidos e não apenas o PO. Não é só porque ele é dono do produto que tudo vai acontecer como ele deseja sem questionamentos.

Mas nós sabemos que esse cenário seria o ideal, mas que na realidade não é assim. Se temos um problema como esse, é sinal de que seu cliente não entendeu como o Scrum funciona e ai é um outro problema que precisa ser tratado antes de tudo. Eu diria que até antes do cliente apresentar o produto, ele já deveria saber o porquê vai rodar o Scrum e saber que as coisas funcionam em um trabalho de equipe e que cada um tem suas responsabilidade e limitações. Se isso não está claro para o seu cliente, não inicie nada. Do contrário, terá problemas e discussões que talvez não compensem. Agora vamos ignorar o cenário anterior. 

Então, Camilo, como escolher a história que vai para o Sprint Backlog?

Por sentimento ou instinto. É isso mesmo! Não há mágica, ou ferramenta, que vai te dizer: “pegue a história X, e a equipe que vai contribuir para isso”. Normalmente, o ScrumMaster pergunta para equipe se a história que está no topo da lista (aquela que tem mais importância para o PO) dá para entregar naquela Sprint. Aquelas nas quais ainda restarem dúvidas e incertezas a respeito da entrega ficam de fora (com o aval e negociação do PO) do Sprint.

A seguir, temos um exemplo pratico (peguei a imagem do livro Scrum from the trenches):

Note: Claro que vamos seguir sempre a ordem de importância para o PO e não pegar as histórias aleatórias.

Vamos supor que o PO não gostou porque a história D está de fora - afinal, a velocidade da equipe só permite entregar até a C. O que fazer?

Em primeiro lugar, o PO não pode obrigar a equipe a pegar a história D (de novo, para você não esquecer). Então ele tem duas opções:

1. É alterar o escopo, para que o time possa fazer uma nova estimativa;
2. Mudar a ordem de prioridade, levando a história para cima do C, daí a equipe é obrigada a pegá-la. Porém, a história C ficaria de fora. 

Mas, o framework Scrum não diz que temos que pegar a história com maior prioridade? Sim. Pegamos a história que está no topo da pilha do product backlog, mas ao olhá-la, identificamos que é grande demais e não cabe dentro do Sprint de duas semanas, ou seja, é pouco tempo para muita coisa (escopo grande). Lembre-se, as histórias deve ser do tipo INVEST.

• Independente: a história não pode ficar bloqueada durante a implementação; ela precisa ter vida por si só;
• Negociável: uma história precisa ter um escopo que pode ser alterado sem perder toda a essência do que se pretende. E que algumas coisas possam ser postergadas para um dos próximos Sprint tranquilamente;
• Valioso: deve agregar valor ao produto e ter um valor de importância dentro do próprio produto;
• Estimável: se não conseguimos estimar com base no que está escrito para história, é porque temos algum problema no que ela se propõe. Então precisamos ver com o PO o que ele está querendo dizer;
• Small: não é preciso ter todas as funcionalidade em única história, sendo assim, ela pode ser pequena para que fique dentro do Sprint;
• Testável: toda história precisa ter uma forma de validar se ela foi implementada corretamente. Então os critérios de aceitação devem existir, para que possamos nos certificar que fizemos algo de acordo com o esperado.

Bom, pessoal, era isso que eu tinha para apresentar para vocês. Não se esqueçam que a responsabilidade de analisar e estimar é da equipe. O que foi escrito pelo PO é o que ele desejaria de ver pronto, mas nem sempre é possível, pois há vários fatores que contribuem para isso, tais como: velocidade da equipe, nível técnico, interrupções, etc. Não é uma tarefa fácil, mas com uma boa comunicação entre a equipe e o PO, sempre terminamos no contexto ideal.

Espero que tenham gostado. Até o próximo artigo!

Compartilhar :

Tweet

✚

Relacionadas