O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar uma luz sobre o que é e como tratar o refinamento do backlog.
Neste artigo
Como tudo começa
As demandas chegam para o Time de fontes distintas: solicitações de clientes, ideias de pessoas do time, reclamações, novas legislações, recomendações, auditoria etc. A maioria das vezes, essas demandas não estão claras o suficiente para que os desenvolvedores comecem a implementá-las de imediato. É necessário esclarecê-las, avaliá-las e priorizá-las dentro de um backlog que já está em andamento.
Refinamento do Backlog
De fato, não há uma única maneira de refinar o backlog. Cada empresa e cada tipo de demanda pode ter um processo de refinamento distinto. A ideia de um membro do time pode ser debatida e avaliada dentro do próprio time. Novas legislações provavelmente contarão com diversas conversas com o pessoal jurídico. Pode ser que existam reuniões ou o Product Owner refinando sozinho até apresentar a demanda para o time. Cada caso é um caso.
Pontuar o Backlog Refinado
Muitos times trabalham com estimativa de esforço utilizando o Planning Poker para avaliar o Retorno sobre o Investimento de cada item no backlog. Resumidamente, é uma reunião em que o Product Owner apresenta o backlog com o valor dos itens refinados (Retorno) e os Desenvolvedores definem o esforço (investimento) necessário para implementar cada item. No final, temos o RoI (Return on Investment) de cada item e conseguimos compará-los com o que está no Backlog e priorizar esses itens.
Essa reunião também serve para os desenvolvedores indicarem para o Product Owner que o item precisa ser mais refinado ou que ele precisa ser fatiado, pois está grande demais para eles se comprometerem com ele.
O refinamento deve ser mapeado?
Todo trabalho que precise de algum esforço do time precisa ser mapeado. Caso contrário ficará como trabalho escondido (esforço que não é visto, por não estar mapeado). Nesse momento é importante utilizar o conceito do Kanban chamado Upstream. Nesse método o Upstream são todas as etapas do fluxo de trabalho que acontecem antes do Ponto de Comprometimento. Ele é justamente o momento de descoberta (discovery) do item. As etapas do Upstream podem ser justamente o refinamento de cada item de trabalho. Durante essas etapas, cada item pode ter uma das três decisões:
- Descartar: Não vale a pena ser feito, pois o esforço é excessivamente alto para o retorno que teremos com o incremento do produto / serviço.
- Shelve: Em português seria algo como “engavetar”. “Colocar na estante” parece mais adequado. É quando reconhecemos que não temos informações suficientes para dar prosseguimento com o item ou não é interessante prosseguir com ele no momento e não conseguimos descartá-lo agora. Então o colocamos na “prateleira” e no futuro voltaremos a refiná-lo.
- Investir: Dar prosseguimento no refinamento até que ele chegue no Ponto de Comprometimento.
Refinamento no Quadro Kanban
Pensando em um quadro Kanban, na verdade, Quadro de Mapeamento do Fluxo de Trabalho, podemos definir algumas etapas que você também pode utilizar.]
A primeira etapa é uma piscina de opções (Options Pool). Também chamada de Piscina de Ideias. São todos os pedidos que existem no seu estado mais cru, não refinado, não valorado, não priorizado. A próxima etapa chamei de refinamento, pois ela depende muito do seu time, como ele trabalha e o que vocês consideram o que realmente precisa ser o refinamento. Uma vez que os itens estão refinados, eles ficam aguardando o momento em que os desenvolvedores ou parte deles irão estimar o esforço. Após isso, o Product Owner, com o ROI calculado, consegue priorizar dentro do Backlog.
O próximo passo eu chamei de Sprint Planning, pois imaginei um quadro de um time que utiliza Scrum, porém poderia ter qualquer outro nome. É o ponto de Comprometimento. A partir daquele momento, a construção começa de fato e o item de trabalho entra no Downstream.
Conclusão
Aqui procuramos desfazer a confusão que acontece sobre o refinamento. Vimos que não é uma única reunião e sim etapas do fluxo de trabalho que nos ajudam a decidir se um item irá compor o nosso backlog e, caso afirmativo, qual a prioridade daquele item frente aos demais. Também vimos que essas etapas devem compor o Quadro Kanban para evitar o trabalho escondido. Espero que lhe seja útil
Se quiser saber mais sobre Scrum, veja o nosso treinamento de Certified ScrumMaster® (CSM). Agora, se quiser conhecer mais sobre gestão de fluxo e mapeamento de Upstream e Downstream, veja o nosso treinamento de Kanban System Design (KSD).
