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.

As Entradas (e o timing)

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.

A Atividade

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);

As Saídas

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.

Os Participantes

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:

https://www.agilealliance.org/glossary/backlog-grooming/

https://www.mountaingoatsoftware.com/blog/product-backlog-refinement-grooming

*muri: desperdícios causados pela irracionalidade e falta de padronização de processos. Ex: necessidade de se tomar muitas decisões antes de executar uma atividade.