O papel do Product Owner no refinamento do Backlog do Produto

O refinamento do backlog do produto é essencial para garantir Sprints produtivas. Segundo o guia do Scrum, não se trata de um evento específico, mas de uma atividade contínua 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 a maneira de conduzir essa atividade.

Para isso, é necessário sair dos modelos teóricos e observar sua aplicação prática. No mundo real, o refinamento é utilizado para preparar o time para o planejamento das próximas Sprints.

As Entradas (e o timing)

Idealmente, o refinamento do backlog deve ocorrer algumas vezes por semana, sem tomar mais do que alguns minutos do time. Deve ter a cadência suficiente para permitir que o time reflita, estude e proponha soluções para as 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 o desenvolvimento do produto. O Scrum Master deve instigar o time a fazer as seguintes reflexões:

• Qual a complexidade? Quais os riscos? Quais as incertezas? Quais são os critérios de satisfação? E se ocorrer determinado evento, o que acontece com a aplicação? (entenda-se esmiuçar os critérios de aceite).

As Saídas

Com base no que foi apresentado pelo PO, o Time Scrum produzirá os requisitos necessários para o desenvolvimento do produto nas Sprints (Sprint Backlog). Isso inclui, mas não se limita a: histórias de usuário, BDDs, critérios de aceite e fluxos de decisão. Com a ajuda do PO, serão identificadas novas situações e definidos 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 ideias, o Time Scrum trabalha para materializar essas expectativas.

O refinamento também serve como preparação para eventos de planejamento, como o release planning. Logo, o PO deve trazer uma ideia de priorização do backlog e trabalhar com o Time Scrum para estimar o tamanho e pensar os encaixes nas Sprints. Nesse momento, podem ser usadas estratégias de estimativa mais simples, como por exemplo: PMG.

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 problema diferente que poderia render um artigo só para ele.

Os Participantes

O core team do Scrum (Ken Schwaber, Mike Cohn) se posiciona 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 dessa atividade.

Há suspeitas de que essa atividade aumenta o "muri", então deve-se ter cuidado em envolver todo o time por muito tempo. O ideal é que o refinamento seja feito em poucos minutos por dia.

Por fim, pode-se, eventualmente, convidar especialistas com habilidades muito específicas para elucidar tópicos que precisem ser esclarecidos.

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