By Apesar de não ser um evento formal no Scrum, por não ser obrigatório, o Product Backlog Refinement é uma atividade vital em muitos times Scrum por trazer clareza aos itens de trabalho e proporcionar alinhamento sobre o produto.
Na prática, nem sempre os times se depararam com um Product Backlog (PB) organizado, priorizado e com stories bem definidas. O que eu vejo com certa frequência são PBs gigantes (com stories para mais de meses de trabalho), itens de trabalho com apenas o título, itens que estão lá parados a mais de seis meses (já vi casos com mais de um ano), stories que mais parecem épicos, bugs que nunca serão corrigidos, tipos de trabalho classificados incorretamente e priorizados do tipo “tudo é importante e urgente”.
O refinamento do PB não resolverá todos esses problemas da noite para o dia já que alguns deles são causados por outras disfunções no time ou até mesmo na empresa. Contudo, estabelecer uma cadência para essa atividade pode agilizar e melhorar a qualidade das entregas.
Fundamentos
“O Product Backlog refinement é o ato de quebrar e incluir definição adicional aos itens do Product Backlog para ter itens menores e mais precisos. Esta é uma atividade contínua para adicionar detalhes, como descrição, ordem e tamanho. Os atributos geralmente variam de acordo com o domínio de trabalho” (Scrum Guide).
O Product Backlog Refinement é facilitado pela PO e representa o momento onde as prioridades do produto são apresentadas para o time assim com as stories (previamente descritas). Se os requisitos não estão claros, então a PO deve providenciar os detalhes solicitados pelos DEVs (pelo time) e atualizar as stories de acordo. Se uma story está muito grande, então deve-se quebrá-la em menores incrementos de valor.
💡 O Product Backlog Refinement é um momento para compartilhar O QUE precisa ser feito, entender os problemas e as necessidades dos usuários/clientes e alinhar o PORQUÊ o time deve trabalhar nisso nas próximas Sprints.
Entradas
- Product Backlog priorizado pela PO
- Product Backlog Items (PBI) correspondente ao Definition of Ready (DOR)
- Sprint Backlog das próximas Sprints criados (apenas como um rascunho ou proposta de entrega)
- Ferramenta ou aplicativo para Planning Poker (caso o time estime os PBIs)
Processo
- PO apresenta as prioridades do produto ao time
- PO apresenta os próximos itens de trabalho (os PBIs)
- PO e DEVs conversam até que cada item cumpra os critérios do DOR
- Se um item de trabalho não está pronto para ser iniciado, então a PO deve providenciar os detalhes faltantes até o próximo refinamento ou antes do início da próxima Sprint
- PO atualiza a descrição e detalhamento dos itens de trabalho (quando necessário)
- PO remove e adiciona itens de trabalho do PB (quando necessário)
- PO pode repriorizar o PB de acordo com as sugestões do time
- DEVs podem criar checklist básico (nada muito extenso) para itens de trabalho a fim de capturar detalhes importantes sobre COMO o trabalho deverá ser realizado
- DEVs jogam o Planning Poker para estimar o tamanho do item de trabalho (considerando esforço, complexidade e riscos) utilizando Story Points (ou qualquer outra unidade de medida utilizada pelo time)
- Scrum team verifica dependências que podem impactar algum item de trabalho
- Scrum team analisa possíveis riscos e impedimentos para o desenvolvimento do produto
Saídas
- Itens de trabalho prontos para serem iniciados nas próximas Sprints (DOR atendido)
- Quantidade de itens de trabalho suficiente para o time trabalhar na próxima Sprint
- Product Backlog atualizado e priorizado
- PO com uma lista de itens que necessitam de esclarecimentos (quando necessário)
Time-box
Não há definição em relação ao time-box do Product Backlog Refinement no Scrum Guide. Contudo, com base na experiência, esse evento pode levar de 1 a 2h. A reunião poderá levar mais tempo dependendo do tamanho do time, da sua capacidade e complexidade dos PBIs.
O time pode necessitar de uma ou duas sessões por sprint para garantir que terão itens de trabalho refinados em quantidade suficiente para a próxima Sprint.
Ferramentas
Planning poker online ou PlanIT poker são ferramentas gratuitas para o Planning Poker. Se você utiliza ferramentas de comunicação como Slack ou MS Teams, há apps que podem ser instalados gratuitamente através da própria plataforma.
O Product Backlog Refinement é uma reunião por vezes negligenciada pelos POs já que tudo está claro e alinhado na sua cabeça. Contudo, faz-se necessário buscar confirmação com o Scrum team uma vez que eles são os responsáveis por implementar as soluções. Além de validar com o time, é interessante dar abertura para que eles possam sugerir formas de resolver os problemas ali apresentados. Pode não parecer, mas as pessoas não estão ali apenas para codificar, muitas delas desejam cocriar e colaborar no desenvolvimento do produto buscando soluções criativas e ágeis para os problemas dos clientes.
⚠️ Não existe bala de prata! Esse é um guia que pode funcionar na íntegra em algumas situações enquanto em outras apenas alguns elementos serão utilizados. Apesar das atividades do processo estarem listadas em sequência, elas nem sempre acontecem na ordem sugerida. É importante fazer a leitura adequada em cada contexto para otimizar ao máximo o tempo com o time e a eficiência dessa reunião.
By 
