O que você precisa saber sobre Product Backlog Refinement (Grooming)

Para que um Sprint possa ser planejado no Scrum e o trabalho possa começar, o Product Backlog precisa estar bem cuidado e preenchido com Product Backlog Items devidamente preparados. É lógico que o Refinement do Backlog precisa acontecer regularmente – mas como isso funciona na prática?

O que significa exatamente o Product Backlog Refinement, no que você deve prestar atenção e por que o Refinement é tão importante, vamos mostrar neste artigo.

O que significa Product Backlog Refinement no Scrum?

Até algum tempo atrás, no Scrum o Product Backlog Refinement ainda era chamado de Backlog Grooming (grooming em português: cuidar). Isso porque no Backlog Refinement o objetivo é cuidar e preparar o Product Backlog com seus Items e Epics de forma que o Scrum Team possa usá-lo como base para o Sprint Planning.

Product Backlog Refinement significa então: Os Product Backlog Items são elaborados, avaliados e priorizados de modo que o Development Team possa montar seu Sprint Backlog a partir deles. Um Product Backlog bem cuidado deve sempre ter em estoque pelo menos Items preparados suficientes para que um Sprint completo possa ser planejado.

O objetivo principal do Backlog Grooming é que o Development Team compreenda a visão do produto do Product Owner e as User Stories criadas por ele, e assim seja capaz de planejar o próximo Sprint de acordo com os objetivos do Sprint.

A propósito: Se você procurar o termo Refinement no Scrum Guide, vai perceber que ele não faz parte dos eventos oficiais do Scrum, como Sprint e Daily Scrum. Na verdade, o Product Backlog Refinement é uma chamada Activity, que acontece como uma reunião. Além do Product Owner e do Development Team, participam do Refinement Meeting o Scrum Master e – especialmente em refinements estratégicos – os Stakeholders.

Como funciona o Backlog Refinement Meeting

Antes do Backlog Refinement propriamente dito vem a preparação:

1. O Product Owner define o objetivo do Sprint (Outcome).
2. De acordo com esse objetivo do Sprint, o PO prioriza o Product Backlog e seleciona os Product Backlog Items (PBIs) mais importantes ou escreve novos.
3. O Scrum Team formula em conjunto uma Definition of Ready (DoR), que define quais características ou nível de detalhamento esses Product Backlog Items devem ter para que o time de desenvolvimento possa incluí-los em um Sprint.

Agora pode começar a execução do Backlog Refinement Meeting:

1. O Product Owner e o time de desenvolvimento discutem os objetivos do Sprint e os PBIs correspondentes. É importante que o PO comunique apenas o objetivo a ser alcançado e não determine como ele deve ser alcançado.
2. O time de desenvolvimento dá seu input. Isso inclui, por um lado, ideias próprias para a implementação baseadas no conhecimento da aplicação ou do produto, e por outro, observações sobre dependências técnicas entre os PBIs, o que pode levar a repriorização de alguns temas.
3. Assim que o time de desenvolvimento e o PO alcançam um entendimento comum sobre um Product Backlog Item, o PO ou um membro do time documenta esse PBI de acordo com a DoR formulada no ponto 3 e registra, por exemplo, critérios de aceitação. Muitos times realizam neste ponto também a estimativa de esforço – chamando de Estimation Poker e não de Planning Poker, já que não acontece no Planning.

O Product Backlog Refinement (Grooming) é importante para o sucesso

Um bom Product Owner leva o Refinement muito a sério. Ele sabe que um Backlog Grooming regular e bem executado estabelece a base para o andamento do Sprint posterior e, portanto, para o sucesso de um produto, pois:

• o Refinement garante que o Product Backlog esteja atualizado e possa ser usado como base para o próximo Sprint Planning.
• através desse tipo de trabalho prévio, o time de desenvolvimento se envolve cedo com os PBIs mais importantes e pode fazer perguntas que de outra forma só surgiriam no Sprint Planning. Isso dá ao PO a oportunidade de encontrar as respostas a tempo para o Planning Meeting.
• os Sprint Planning Meetings ficam mais curtos, pois agora só precisa ser discutido o "Como" da implementação, já que o "O quê" foi esclarecido pelo Refinement. Além disso, no cenário ideal os PBIs já foram estimados pelo time e podem ser puxados conforme a Velocity. Assim se evita que no Sprint Planning não haja PBIs suficientemente preparados disponíveis.
• através do trabalho conjunto nos PBIs, PO e Development Team desenvolvem mais rapidamente um entendimento comum da visão, objetivos e tarefas.
• todas as ideias do time de desenvolvimento para implementação de um PBI são registradas no Refinement.
• acontece uma enorme transferência de conhecimento, já que o PO transmite ao time cada vez mais contexto sobre clientes, modelo de negócio etc. através do Refinement.
• no Sprint, o time pode focar mais no trabalho propriamente dito, pois as perguntas mais importantes foram esclarecidas no Refinement.

O que você deve observar no Product Backlog Refinement!

1. Antes de priorizar ou ordenar definitivamente os PBIs no Product Backlog, você deve ter uma noção do tamanho dos itens individuais, pois isso determina os custos, que por sua vez influenciam a prioridade. O tamanho no Scrum é estimado em unidades relativas como Story Points.
2. O Scrum não determina quando e com que frequência você deve realizar o Product Backlog Refinement. Nossa recomendação é: 1x por semana, por exemplo no meio do Sprint. Alguns times realizam refinements diários e mais curtos, o que depende principalmente da disponibilidade do Product Owner.
3. Como nos eventos e outras activities no Scrum, também no Product Backlog Refinement recomenda-se uma realização regular em um ritmo fixo, para que se crie uma rotina.

Conclusão sobre o Product Backlog Refinement

Um Product Backlog Refinement regular e bem feito é absolutamente essencial para um Sprint bem-sucedido – e, portanto, para o sucesso do produto. Se você já trabalha como Product Owner ou quer se preparar para essa função empolgante e praticar o Product Backlog Refinement na prática, teremos prazer em apoiá-lo com um treinamento de Product Owner adequado.

Download Template Backlog Refinement