Neste capítulo, você vai ver como o Product Owner prioriza: como decide o que entra primeiro quando tudo parece urgente. Priorizar é, na prática, aprender a dizer não com critério, e é a habilidade que mais distingue um Product Owner eficaz.

Priorizar é ordenar o Product Backlog de forma que os itens de maior valor, considerando risco, custo, dependências e aprendizado, fiquem no topo. O Guia do Scrum fala em ordenar, não em classificar: cada item tem uma posição, não uma etiqueta de “alta prioridade” compartilhada com outros trinta. A ordem é responsabilidade do Product Owner.

Por que “tudo é prioridade” não funciona

Quando três itens são prioridade máxima, o time escolhe por conta própria ou faz um pouco de cada um. Nos dois casos, o Product Owner abdicou da decisão. Ordenar força a escolha: este item vem antes daquele. É desconfortável, e é exatamente por isso que o papel existe.

Critérios que entram na ordem

• Valor
  Quanto o item aproxima o produto da meta, para a persona primária.
• Risco e incerteza
  Itens que reduzem uma dúvida grande sobem, mesmo que o valor direto seja pequeno.
• Custo e esforço
  Estimado com os Developers, nunca pelo Product Owner sozinho.
• Dependências e prazo
  O que precisa existir antes, e o que tem data externa real.

Técnicas que ajudam a conversa

Nenhuma técnica decide pelo Product Owner. Elas organizam a discussão e tornam o critério visível para os stakeholders.

• Valor versus esforço: uma matriz 2×2 para separar rapidamente o que é barato e valioso do que é caro e duvidoso.
• MoSCoW: must, should, could, won’t. Útil para negociar escopo de uma release; perigoso se tudo vira must.
• Modelo Kano: distingue o básico esperado, o que aumenta satisfação e o que encanta. Evita investir em encantamento com o básico quebrado.
• Custo do atraso: quanto se perde por semana sem o item. Faz a conversa sair da opinião e ir para o número.

Como dizer não

Imagine o curador de uma exposição. O museu tem mil obras no acervo e espaço para cinquenta. Dizer não a novecentas e cinquenta não é desprezo pelas obras; é o que torna a exposição coerente. O Product Owner cura o backlog da mesma forma. O não vem acompanhado de um porquê ligado à visão e à meta, e de um “ainda não” quando fizer sentido. Stakeholders aceitam melhor um não fundamentado do que um sim que nunca se cumpre.

Com os itens ordenados, o próximo capítulo mostra como comunicar essa ordem ao longo do tempo sem prometer datas que o empirismo não sustenta: o roadmap e o plano de release.