O que é o Refinamento do Backlog?

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. 

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.]

Um quadro com o refinamento do backlog que é explicado no texto.
Refinamento do Backlog mapeado no fluxo de trabalho através do Upstream

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

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…

Após alguns anos desenvolvendo produtos e ajudando outras empresas a fazer tal, gostaria de listar com vocês alguns erros comuns que percebi ao longo dessa jornada. Olhando para as 4 Áreas de Domínio da Agilidade (Negócio, Cultural, Organizacional e Técnica)…

Uma das principais habilidades que desenvolvemos enquanto consultores é a de fazer boas perguntas. Uma vez que as pessoas percebem o poder que tem uma boa pergunta, colocada ali na hora certa e que muda o destino de uma reunião,…

Há cerca de uma semana um estudo com um título bombástico tomou conta da web: “268% dos projetos que passaram a utilizar Métodos Ágeis pioraram e 56% passaram a falhar”, dizia o título. E ao ler o conteúdo, pareceu que…