Scrum:Definindo as estórias para o Sprint Backlog


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!!

Scrum: Lidando com estimativa e escopo com o cliente


Olá Pessoal,

Firme e forte na série Scrum. Hoje vamos ver como lidar com estimativa e escopo com o cliente, quem aqui não teve aquela solicitação do cliente: “será que não dar para diminuir um pouco a estimativa?”. Mas, nem sempre dá, porém o cliente sempre insiste. Então como resolver esse problema e ao mesmo tempo deixar o cliente satisfeito? Veremos a seguir.

Lets GO…

 Lidando com estimativa e escopo com o cliente situação comum e esperada

 Quem nunca passou pela situação a seguir? Não necessariamente com cliente apenas, mas com gerente de projetos, arquitetos etc. Se tua estimativa está alta na visão deles, é capaz, de presenciar um infarto rs ;).

Note: Estimar não é uma tarefa fácil, envolve vários fatores o quanto o time conhece as tecnologias, o produto, a experiência profissional, e os mais recentes chegados na equipe terão dificuldade em estimar inicialmente, pelos fatores citados anteriormente sendo assim o ScrumMaster deve auxiliar os novatos dando um coach na estimativa.

“O cliente diz, eu sei que você tem uma equipe técnica qualificada, com os melhores profissionais, será que não dá para diminuir um pouco a estimativa?”

Nesse caso o cliente está usando a qualidade interna, (aquilo que ele não ver) como fator para reduzirmos à estimativa, mas ele não quer diminuir o escopo. Claro que não permitiremos isso, sacrificar à qualidade interna na maioria das vezes (para não dizer sempre) é péssima idéia, lembre-se disso: “uma vez que se permita que uma base de código se deteriore, é muito difícil recuperar a qualidade mais tarde”. Não conte com refactoring, pois fazê-lo depois de tudo há um custo e nem sempre o cliente vai querer pagar por isso. Mas, como responder ao cliente a pergunta acima?

Uma das formas de responder é tentar convencê-lo de reduzir o escopo para algo mais especifico e remover aquela parte avançada, que normalmente vai virar uma nova estória que pode entrar no próximo Sprint. Um exemplo:

Se o cliente quer que todas as mensagens iterativas com o usuário sejam exibidas, por que não implementar as mais importantes e aquelas com menos importância deixar para um futuro, ou seja, aquelas que não causam impacto no entendimento ou funcionalidade da aplicação, podem ficar para os próximos Sprints. Outra situação é que ele quer um WebService para aplicação, mas o ScrumMaster viu junto com a equipe que não dá para entregar dentro do tempo e com base no escopo atual do WebService. A missão agora é convencer o cliente diminuir o escopo caso ele queira ver algo de WebService pelo menos iniciado no Sprint corrente.

Sei que não é uma tarefa fácil convencer o cliente disso, mas se ele está envolvido com o time e Scrum, ele sabe dos problemas que pode ter se tentar ir além da capacidade de entrega da equipe, é por isso que o PO não dita o que deve entrar no Sprint. É a equipe que vai pegando os itens até chegar no limite. Então qual a solução? Negociação e validar o escopo com o PO, essa é a forma mais adequada para não afetar a qualidade interna do produto, alguém uma vez disse em algum lugar que a qualidade não é negociável.

Vou ficando por aqui e espero que tenham gostado do post.

Abraços, see ya!!