Refinamento do backlog: como preparar itens para a sprint
O refinamento do backlog é o trabalho que decide se a Sprint Planning dura uma hora ou uma tarde inteira. Quando os itens chegam à planning claros, pequenos e com critérios de aceite, o time escolhe, planeja e começa. Quando chegam vagos, a reunião vira uma sessão de descoberta às pressas, o plano sai frágil e as dúvidas reaparecem no meio da Sprint.
Muitos times sabem disso e ainda assim tratam o refinamento como uma reunião que pode ser cancelada quando a semana aperta. O resultado aparece dias depois: histórias que não cabem na Sprint, dependências descobertas tarde e Developers esperando resposta do Product Owner.
O guia a seguir mostra o que o Guia do Scrum diz sobre o assunto, quem participa, como conduzir uma sessão passo a passo e como saber se o refinamento está funcionando.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é refinamento do backlog, segundo o Guia do Scrum
O Guia do Scrum 2020 define o refinamento do Product Backlog como o ato de dividir e detalhar os itens do backlog em itens menores e mais precisos. É uma atividade contínua, que acrescenta detalhes como descrição, ordem e tamanho. O Guia acrescenta três pontos que orientam a prática:
- Os Developers que farão o trabalho respondem pelo tamanho dos itens. O Product Owner pode influenciá-los, ajudando a entender e escolher entre alternativas, mas não estima por eles.
- Itens que podem ficar prontos dentro de uma Sprint são considerados aptos para seleção na Sprint Planning. Eles costumam chegar a esse grau de transparência depois do refinamento.
- O refinamento não é um evento. Os eventos do Scrum são cinco (Sprint, Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective). Refinar é trabalho que acontece ao longo da Sprint, na forma que o time escolher.
Dois detalhes ajudam a ler material antigo. O termo grooming, ainda comum em ferramentas e conversas, é o nome que versões anteriores do Guia usavam; o atual é refinement. E edições anteriores sugeriam um limite de tempo para o refinamento, como fração da capacidade do time; a versão de 2020 retirou essa referência e deixou a decisão com o Scrum Team.
O lugar do backlog no framework está no guia completo de métodos ágeis e Scrum.
Quem participa e quando fazer
Participantes fixos: o Product Owner, que traz o contexto e a ordem, e os Developers, que fazem perguntas, propõem divisões e estimam. O Scrum Master pode facilitar, principalmente enquanto o time aprende a prática.
Participantes eventuais: especialistas e partes interessadas, convidados quando o item depende do conhecimento deles. Um analista fiscal para uma regra de imposto, um usuário-chave para um fluxo de atendimento.
Formatos mais comuns:
| Formato | Como funciona | Quando serve |
|---|---|---|
| Sessão fixa | Uma ou duas sessões por Sprint, em dia e horário fixos | Times que estão começando ou com backlog desorganizado |
| Contínuo | Pequenas conversas sempre que o Product Owner tem um item pronto para discutir | Times maduros, com PO muito disponível |
| Misto | Sessão fixa curta mais conversas pontuais durante a semana | A maioria dos times |
Horizonte: refine o suficiente para uma ou duas Sprints à frente. Detalhar itens que só entrarão daqui a três meses é desperdício, porque eles provavelmente vão mudar.
Como fazer o refinamento do backlog: passo a passo
Antes da sessão (Product Owner)
- Escolha os itens. Separe os primeiros itens da ordem do backlog que ainda não estão aptos para a Sprint, em quantidade compatível com o tempo da sessão.
- Traga o porquê. Para cada item, tenha à mão o problema do usuário, o objetivo e qualquer dado que justifique a posição dele no backlog.
- Antecipe as dúvidas óbvias. Regras de negócio, telas de referência, contatos de quem pode responder. Compartilhe com o time um ou dois dias antes.
Na sessão (Product Owner e Developers)
- Apresente o item em poucos minutos. Quem é o usuário, o que ele precisa e por que agora.
- Abra para perguntas. Os Developers questionam regras, exceções, dados, integrações e impacto em outras partes do sistema. As respostas que ninguém tem viram ação com dono.
- Escreva ou ajuste os critérios de aceite. Exemplos concretos funcionam melhor que regras abstratas: "pedido com valor acima do limite vai para aprovação do gerente".
- Divida o que é grande demais. Se o time não acredita que o item cabe numa Sprint, quebre por etapa do fluxo, por regra de negócio ou pelo caminho feliz primeiro. As formas de quebra e a diferença entre épico, história e tarefa estão em épico, história de usuário e tarefa.
- Estime. Os Developers dão o tamanho, com a técnica que o time usa (planning poker, tamanhos de camiseta ou contagem de itens). Grandes divergências de estimativa costumam indicar entendimento diferente do item: volte ao passo 5.
- Registre riscos e dependências. Integração com outro sistema, aprovação de outra área, ambiente que ainda não existe.
- Confirme se o item está apto. Se o time usa uma lista de critérios para isso, aplique-a aqui. A Definition of Ready explica como montar essa lista sem que ela vire burocracia.
Depois da sessão
- Atualize o backlog. Descrição, critérios, estimativa e ordem precisam estar na ferramenta no mesmo dia.
- Feche as pendências. As perguntas sem resposta têm dono e prazo antes da próxima Sprint Planning.
Modelo de pauta de refinamento (60 minutos)
Copie e adapte ao tamanho do seu time:
REFINAMENTO DO BACKLOG: [nome do produto] Data: [dd/mm] Sprint alvo: [n]
Facilitação: [nome] Participantes: PO, Developers, convidados: [nomes]
00-05 Contexto: Meta do Produto e o que mudou desde a última sessão
05-50 Itens (cerca de 10 minutos cada)
Item: [título]
Problema e objetivo:
Perguntas e respostas:
Critérios de aceite:
Divisão (se necessário):
Tamanho estimado:
Riscos e dependências:
Situação: apto / precisa de nova rodada / descartado
50-55 Pendências: pergunta, dono, prazo
55-60 Próximos itens a preparar para a próxima sessão
Se um item consome mais de 15 minutos sem convergir, pare, registre as dúvidas e marque uma conversa menor só com quem precisa estar nela. A sessão inteira não deve ficar presa a um item.
Exemplo ilustrativo de item refinado
Uma distribuidora de alimentos está construindo um aplicativo para os representantes comerciais registrarem pedidos na visita ao cliente. O exemplo é ilustrativo.
Antes do refinamento: "Representante faz pedido pelo app."
Depois da sessão:
- História: como representante, quero registrar um pedido de um cliente já cadastrado, para não depender de anotar em papel e digitar depois.
- Critérios de aceite: a lista de produtos mostra preço da tabela do cliente; quantidade acima do estoque gera aviso, mas não bloqueia; o pedido fica salvo no aparelho se não houver conexão e é enviado quando o sinal voltar; o cliente recebe a cópia do pedido por e-mail.
- Divisões feitas: cadastro de cliente novo e aplicação de desconto ficaram como itens separados, para Sprints seguintes.
- Tamanho: estimado pelos Developers como cabendo na Sprint, depois da divisão.
- Dependência: a área de TI precisa liberar acesso ao serviço de tabela de preços. Dono: Product Owner. Prazo: antes da próxima planning.
Repare que a sessão não decidiu como construir. Isso é trabalho dos Developers na Sprint Planning, quando o item vira tarefas no Sprint Backlog.
Como saber se o refinamento está funcionando
Alguns sinais simples, que o Scrum Master pode acompanhar a cada Sprint:
- A Sprint Planning termina dentro do tempo e quase não há perguntas de entendimento sobre os itens.
- Há itens aptos para pelo menos uma Sprint e meia no topo do backlog, o que dá margem para mudar de ideia.
- Poucas histórias são divididas ou reestimadas no meio da Sprint.
- Dependências raramente são descobertas depois que o trabalho começou.
Se os sinais forem ruins, a causa costuma estar em três lugares: Product Owner sem tempo para preparar, sessões sem os Developers que farão o trabalho ou backlog sem ordem clara. Nesse último caso, vale revisar o método de ordenação; as técnicas de priorização ágil ajudam a escolher um critério que o time entenda.
Erros comuns no refinamento
- Refinar só na véspera da planning. Sem tempo para buscar respostas, as dúvidas entram na Sprint.
- Product Owner chegando sem preparo. A sessão vira leitura de tela de ferramenta.
- Discutir solução técnica em detalhe. O refinamento esclarece o quê e o tamanho; o desenho detalhado fica para a Sprint.
- Só uma parte do time participa. Quem não ouviu a conversa vai estimar e construir com outra interpretação.
- Tratar o refinamento como contrato. O item refinado continua aberto a ajustes quando o time aprende algo novo.
O que fazer agora
Olhe o topo do seu Product Backlog e conte quantos itens estão aptos para a próxima Sprint. Se forem menos do que o time costuma entregar, marque uma sessão com a pauta acima esta semana e defina quem prepara os itens seguintes. Depois, leve os itens prontos para a Sprint Planning. Para aprofundar a descoberta, as métricas e a priorização que alimentam um bom backlog, o curso Gestão de Produto da Projeto Diário reúne noventa videoaulas sobre esses temas e inclui os dois exames da PMCert.
