O refinamento do backlog do produto é valioso na obtenção de Sprints produtivas. Segundo o guia do Scrum, não se trata de um evento novo, mas uma atividade recorrente a ser conduzida com o time de desenvolvimento.
Como o framework é pouco prescritivo, cabe ao empirismo de cada time Scrum, definir a frequência e maneira de condução da atividade.
Assim, teremos que sair dos modelos teóricos e observar sua aplicação prática para obter essas respostas. No mundo real, o refinamento tem sido usado para preparar o time para o planejamento para as próximas sprints.
Idealmente, o refinamento do backlog deve ocorrer algumas vezes por semana, e não deve tomar mais do que alguns minutos do time. Ele deve ter a cadência suficiente para permitir que o time reflita, estude, e proponha saídas para dificuldades técnicas que enfrentarão nas próximas sprints.
Como entradas, o product owner deve trazer o backlog do produto representado por meio de wireframes, protótipos, desenhos, fluxos de decisão, jornadas do usuário, personas e critérios de satisfação. Sempre com previsão para as 2-3 próximas Sprints.
O product owner começa a apresentar os artefatos que servirão como base para desenvolvimento do produto. O Scrum Master deve instigar o time a fazer as seguintes reflexões:
· O quanto é complexo; o quanto tem de risco; o quanto tem de incerteza; quais as condições de satisfação; e se ocorrer tal evento, o que acontece com a aplicação; (entenda-se esmiuçar os critérios de aceite);
Como saídas, baseado no que foi apresentado pelo PO, o Time Scrum produzirá os requerimentos necessários para o desenvolvimento do produto nas Sprints (Sprint Backlog). Isso inclui, mas não se limita a: histórias de usuários, BDDs, critérios de aceite, fluxos de decisão. Com a ajuda do PO, serão identificadas novas situações e sairão novos critérios de aceite para as histórias de usuário.
Em síntese, enquanto o PO cuida da concepção do produto no mundo das idéias, o Time Scrum trabalha para materializar essas expectativas.
O refinamento também serve para uma preparação para os eventos de planejamento, como o release planning. Logo, o PO deve trazer uma idéia de priorização do backlog, e trabalhar com o Time Scrum para estimar o tamanho e pensar os encaixes nas Sprints. Nesse momento pode-se trabalhar com estratégias de estimativa mais simples, como por exemplo: PMG.
Aqui um ponto delicado:
Quando o Time Scrum faz a ordenação do backlog, ele já traz consigo uma percepção sobre o andamento da sprint atual. Assim as próximas sprints podem ser “mais ou menos carregadas” de acordo com esse “sentimento”.
Discussões à parte, a meta da sprint atual é INVIOLÁVEL e todo o trabalho combinado deve ser entregue para a review.
ISTO É SCRUM!!!
… se um time Scrum – de maneira recorrente – não está conseguindo entregar a meta das sprints, temos um outro problema que poderia render um artigo só para ele.
Aqui, o core team do Scrum (Ken Schwaber, Mike Cohn) se posicionam assim: o refinamento não pode consumir mais que 10% do tempo do time. Quanto aos participantes, eles recomendam que 50% do time Scrum participe desta atividade.
Há suspeitas que esta atividade aumenta o muri, logo deve-se ter cuidado em envolver todo o time por muito tempo. Ideal, novamente, é que se faça o refinamento em poucos minutos por dia.
Por fim, pode-se, eventualmente, convidar especialistas, que tenham algum skill muito específico, para elucidar tópicos que precisem ser elucidados.
Para saber mais:
