Product Owner e gestão do backlog: valor, histórias de usuário e priorização

A parte mais difícil de construir software não é construí-lo. É decidir o que construir, em que ordem e o que deixar de fora, e fazer isso repetidamente à medida que o mercado, os usuários e a realidade técnica se movem. É exatamente essa decisão que cabe à responsabilidade do product owner sustentar, e um product backlog é simplesmente a forma escrita atual da resposta.

A maioria dos backlogs falha como resposta. Eles acumulam todo pedido que alguém já fez, são ordenados por quem reclamou por último e contêm itens tão vagos que o time precisa adivinhar. Este guia trata de fazer o backlog realizar um trabalho útil: o que a responsabilidade realmente exige, como escrever itens que valham a pena construir, como manter a lista refinada e como ordená-la de forma defensável. O guia do framework Scrum cobre os eventos que consomem o backlog; aqui olhamos para o que os alimenta.

Maximizar valor é uma responsabilidade, não uma lista de tarefas

O framework diz que o product owner é responsável por maximizar o valor do produto resultante do trabalho do time. Duas palavras dessa frase carregam todo o peso. Maximizar implica escolher entre opções em que errar tem um custo real, o que significa que um product owner precisa poder dizer não, publicamente e com frequência. Responsável implica que a organização de fato respeita as decisões: se um diretor consegue reordenar o backlog só de entrar na sala do time, a responsabilidade é apenas nominal.

Três coisas tornam essa responsabilidade viável na prática. A primeira é uma visão de produto: uma declaração curta de quem o produto atende, que problema ele resolve para essas pessoas e por que ele é diferente. A segunda é um product goal: o próximo objetivo significativo nesse caminho, concreto o bastante para que se saiba quando foi atingido e estável por mais de um sprint. A terceira são as evidências: dados de uso, volume de suporte, receita, entrevistas, experimentos; qualquer coisa que transforme uma discussão sobre ordem em um debate sobre medições, e não em uma disputa de opiniões.

Um product owner sem visão produz um backlog sem forma. Um product owner sem evidências produz um backlog ordenado por hierarquia.

Escrevendo itens que sobrevivem ao contato com um time

O formato de história de usuário (como <usuário>, eu quero <capacidade>, para que <benefício>) é uma convenção, não uma regra de algum framework. Todo o seu valor está na terceira cláusula: ela obriga quem escreve a declarar um motivo, e uma história cujo "para que" está vazio ou é circular normalmente não deveria ser construída. O formato é um lembrete de uma conversa, não uma especificação, e por isso um item que nunca foi discutido com o time não está pronto, por mais bem escrito que esteja.

O checklist INVEST é o teste de qualidade habitual para um item.

Os critérios de aceitação tornam a última propriedade concreta. Eles devem descrever comportamento observável, incluindo os caminhos de erro, e pertencem ao item, e não a um documento de testes separado. Um estilo em cenários (dado um estado inicial, quando algo acontece, então isto é observável) é natural de ler e se traduz diretamente em testes automatizados, que é a ponte que o BDD com Cucumber formaliza. Mantenha poucos critérios; vinte critérios em um único item são um sinal de que ele precisa ser quebrado.

Repare na diferença em relação à Definition of Done. Os critérios de aceitação são específicos de um item e respondem "construímos a coisa certa?"; a Definition of Done vale para todos os itens e responde "construímos do jeito certo?". Confundir as duas produz itens que passam nos seus critérios e ainda assim não podem ser liberados.

Refinamento como atividade contínua

Refinamento é o trabalho constante de adicionar detalhes, estimativas e ordem aos itens do backlog para que o topo da lista esteja sempre pronto para ser selecionado. O framework o descreve como uma atividade contínua, e não como um evento, e isso faz diferença: times que o tratam como uma única reunião de noventa minutos por sprint tendem a chegar ao Sprint Planning com itens nos quais ninguém pensou.

O que o refinamento produz é um topo de backlog pronto. Uma definição de pronto (definition of ready) viável: o item foi discutido com os desenvolvedores, tem critérios de aceitação, não tem dependência externa não resolvida, é pequeno o bastante para ser concluído em um sprint e tem uma estimativa com a qual o time se sente confortável. Dois ou três sprints de itens assim bastam; refinar além disso é desperdício, porque a ordem do que está abaixo vai mudar antes de você chegar lá.

Hábitos úteis: reserve para o refinamento algo entre cinco e dez por cento do tempo do time; refine com o time inteiro, para que testers e o pessoal de operações identifiquem problemas cedo; aplique um timebox a cada item e deixe de lado o que se estender demais para uma investigação separada; e quebre os itens durante o refinamento, e não no Sprint Planning, quando já não há tempo para pensar.

Ordenando o backlog

Ordenar o backlog é o ato de maior consequência do product owner, e nenhuma técnica é a correta para todas as situações.

Valor versus esforço. Posicione cada item em dois eixos e comece pelo quadrante de valor alto e esforço baixo. É rudimentar e geralmente basta, principalmente em um backlog pequeno em que todos compartilham o contexto.

WSJF (weighted shortest job first). Um modelo de pontuação popularizado pelos frameworks de agilidade em escala. Você estima o custo do atraso (cost of delay) como a soma de três pontuações relativas (valor para o usuário ou para o negócio, criticidade temporal e redução de risco ou habilitação de oportunidades) e divide pelo tamanho do trabalho. Uma comparação com números:

A correção da busca vence mesmo sendo o item de menor valor, porque é barata e pode ser feita agora. É esse o ponto da técnica: ela favorece trabalhos curtos com custo do atraso relevante e deixa o trade-off explícito o bastante para ser debatido. Seu ponto fraco é a falsa precisão: as entradas são estimativas relativas, então trate o resultado como uma indicação de ranking, e não como um cálculo.

MoSCoW. Must, should, could, won't-this-time (obrigatório, desejável, opcional, não desta vez). Útil diante de um prazo fixo em que o escopo precisa ser flexível, e pela disciplina que a quarta categoria impõe. Seu modo de falha é bem conhecido: tudo vira obrigatório. Uma regra comum é que os "must" não passem de cerca de sessenta por cento da capacidade disponível.

Kano. Classifica as funcionalidades pela forma como a satisfação reage a elas: expectativas básicas, cuja ausência gera irritação mas cuja presença passa despercebida; funcionalidades de desempenho lineares; e fatores de encantamento. É um bom corretivo para backlogs cheios de fatores de encantamento enquanto uma expectativa básica, como a redefinição de senha, está quebrada.

Use uma como técnica principal e as outras para questionar o resultado. A ordenação é também o momento em que entram dependências e riscos: um item com uma dependência de prazo longo pode precisar começar antes do que o seu valor sozinho justificaria, o que se conecta diretamente com estimativa e planejamento.

Quebrando itens grandes

Quebrar itens é a habilidade que mais melhora o fluxo, porque itens pequenos terminam, e terminar é o que gera feedback. A regra é fatiar na vertical (cada fatia atravessa todas as camadas e entrega algo observável), e não na horizontal por componente, o que produz quatro itens e nenhum software funcionando até que o último seja entregue.

Padrões de quebra confiáveis:

• Por etapa do fluxo. Primeiro o caminho feliz de ponta a ponta; validação, casos de borda e administração depois.
• Por regra de negócio. Uma moeda, um país, um tipo de cliente primeiro; generalize depois.
• Por interface. Uma API funcionando antes da tela caprichada, ou uma tabela simples antes do gráfico interativo.
• Por variação de dados. Trate agora o formato de registro mais comum e depois os formatos legados raros.
• Por operação. Criar e ler antes de atualizar e excluir, se essa ordem corresponder ao uso real.
• Spike e depois construção. Quando um item não é estimável, separe uma investigação com timebox, com uma pergunta definida e uma resposta por escrito como entregável.

Se uma fatia não pode ser descrita como algo que um usuário perceberia, provavelmente é uma tarefa e não uma história, e seu lugar é dentro de outro item.

Stakeholders e roadmaps

Um product owner passa uma parcela surpreendente da semana fora do time. Mapeie os stakeholders por influência e interesse, combine como cada grupo será mantido informado e direcione os pedidos para o backlog, e não para a caixa de entrada do time. A Sprint Review é o principal canal agendado e funciona melhor quando parece mais uma conversa de trabalho sobre o que fazer a seguir do que uma demonstração para aprovação.

Os roadmaps são onde a honestidade se perde com mais frequência. Um roadmap de funcionalidades com datas vira um conjunto de promessas que nunca foram estimativas, e cada atraso vira um problema de credibilidade. Duas alternativas resistem melhor às mudanças: um roadmap baseado em objetivos, que nomeia o resultado de cada horizonte em vez das funcionalidades, e um roadmap now-next-later, em que só a coluna "now" tem datas. Ambos permitem mudar o mecanismo sem quebrar o compromisso. Seja qual for a sua escolha, mantenha-o visível no mesmo sistema que o backlog para que ele não possa divergir silenciosamente; veja ferramentas de gestão de projetos para os trade-offs nesse ponto.

Principais pontos

• A responsabilidade é maximizar valor, o que exige autoridade para dizer não e uma organização que respeite a ordenação.
• Um product goal dá direção ao backlog; sem ele, as discussões sobre ordem não têm nenhum parâmetro de comparação.
• Itens são lembretes de conversas: INVEST e critérios de aceitação concretos os mantêm pequenos, valiosos e testáveis.
• O refinamento é contínuo, consome algo entre cinco e dez por cento do tempo do time e deve manter no topo dois ou três sprints de trabalho pronto, e não mais que isso.
• WSJF, MoSCoW, Kano e valor versus esforço expõem, cada um, um trade-off diferente; escolha um como principal e use os outros para questionar o resultado.
• Quebre na vertical para que cada fatia entregue algo observável, e coloque defeitos e trabalho técnico na mesma lista ordenada que as funcionalidades.