Tag: scrum

olá Pessoal,

Demorei um pouco, pois os ultimos dias tem sido corrido, mas está aqui mais um post da série Scrum, hoje vou apresentar como é que a equipe define quais estórias estarão no Sprint Backlog do Sprint que inicia amanhã. Vimos em um dos post anteriores que o PO é um cara 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”. Antes de começar o post queria compartilhar com vocês um vídeo muito interessante desenvolvido pela FIAP. Não é fazer propaganda da instituição, pelo contrário o vídeo foi feito com objetivo informativo sobre o mercado de TI. Vejam:

Lets go

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

Essa é uma pergunta clássica. Eu já ouvir alguns comentários que talvez o PO ou SM deveria fazer isso. Eu acho que se Scrum fosse um framework que funcionasse com base em quem tem o nível mais alto(para não dizer função) é 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 papeis apenas. Enfim, apesar do PO ter escrito toda história e em alguns casos ser o responsável pelo investimento no projeto, com Scrum isso não dar o direito de dizer: “a estó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 questão é quem tem a bola da vez aqui é o time, ou seja, todos estão envolvidos e não apenas o PO. Não é porque ele é dono do produto que tudo vai acontecer como ele deseja sem questionamentos. Se temos um problema como esse é sinal que seu cliente não entendeu como Scrum funciona e ai é um outro problema que precisa ser tratado antes de pensar quando vai acontecer a reunião de planejamento.Eu diria que até antes do cliente apresentar o produto, ele já deveria saber o porque vai rodar Scrum e saber que as coisas funciona em um trabalho de equipe e 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 compense. Agora vamos ignorar o cenário anterior, trouxe apenas fazer uma citação do mundo real :). Então, Camilo como escolher a estória que vai para o Sprint Backlog?

Por sentimento ou instinto. É isso mesmo não há mágica nem ferramenta que vai ti dizer: “pega a história X, e sim a equipe que vai contribuir para isso”. Normalmente o ScrumMaster pergunta para equipe se a estória que está no top da lista(aquela que tem mais importância para o PO) dar para entregar naquela Sprint. Aquelas que ficarem com dúvidas e incertezas da entrega fica de fora (com o aval e negociação com PO) do Sprint.

A seguir temos um exemplo, pratico de um Product Backlog:

Imagem do livro Scrum and XP from the Trenches

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

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

Primeiro: O PO não pode obrigar à equipe pegar(de novo, para você não esquecer). Então ele tem duas opções:

1. é alterar o escopo, possivelmente quebrando e o time re-estimar e ver se é possível.

2. ele mudaria a ordem de prioridade levando a estória para acima do C, daí o team é obrigado a pegar. Porém, a estória C ficaria de fora. Mas, o framework Scrum não diz que temos que pegar a estória com maior prioridade?

Sim. Pegamos a estória que está no topo da pilha do product backlog, mas ao olhar ela identificamos que é grande demais e não cabe dentro do Sprint de duas semanas, ou seja, é pouco tempo para muita coisa(escopo grande) em uma única estória. Lembre-se, as estórias deve ser do tipo INVEST.

• – Independente: a estória não pode ficar bloqueada durante a implementação, ela precisa ter vida por si só;

• – Negociável:uma estória precisa ter um escopo que pode ser alterado sem perder toda a essência do que se pretende e algumas coisas podem ser postergadas para um dos próximos Sprint tranquilamente.

• – Valioso: deve agregar valor ao produto, ter um valor de importância dentro do produto

• – Estimável: se não conseguimos estimar com base no que está escrito para estória, é porque temos alguma problema no que ela se propõe atingir. Então precisamos ver com o PO o que ele está querendo dizer;

• – Small: não precisa ter todas as funcionalidade em única estória, sendo assim pode ser pequena para que fique dentro do Sprint.

• Testável: toda estória precisa ter uma forma de validar se ela foi implementada corretamente. Então os critérios de aceitação devem existir, para que podemos nos certificar que fizemos algo de acordo com o esperado.

Então era isso pessoal que eu tinha para apresentar para vocês quando estiverem pegando as estórias do Product Backlog e trazendo para o Sprint Backlog. Não se esqueçam que a responsabilidade de analisar e estimar uma estória é da equipe.
O que foi escrito pelo PO para estória é o que ele desejaria(nem sempre querer é poder) 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.

Vou ficando por aqui espero que tenham gostado.

Abraços, see ya!!