Conceito e mecanismo
O Product Backlog torna visível o trabalho necessário para melhorar o produto. A sua ordenação é responsabilidade do Product Owner, embora a análise beneficie da equipa e dos stakeholders. Um pedido não ganha prioridade apenas por vir de alguém influente ou por já ter uma estimativa detalhada. Compara contribuição para o objetivo, restrições, custo de atraso e aprendizagem necessária. Estes são critérios de decisão do exercício, não uma fórmula obrigatória de Scrum. Os Developers são responsáveis pelo dimensionamento do trabalho; o Product Owner ajuda a esclarecer escolhas e consequências.
Aplicação guiada
Uma alteração de interface compete com uma investigação de reconciliação cujo risco é desconhecido. Um pequeno trabalho de descoberta pode mudar a ordem das duas opções. Refina o suficiente para apoiar a próxima decisão, dividindo trabalho quando isso permite entregar e aprender mais cedo. Regista hipóteses sem fingir precisão. Se o Product Owner delegar a descrição de itens num analista, continua responsável pela gestão eficaz do backlog. Uma decisão fundamentada pode ser contestada com informação nova; não depende de obter unanimidade em cada posição.
Um item de seis semanas é dividido por fluxo de utilizador, permitindo testar uma primeira capacidade utilizável.
Armadilhas comuns
Priorizar pelo cargo do solicitante; tratar estimativas como certezas; detalhar itens distantes antes de validar necessidade.
Tópicos relacionados: Colaboração, autogestão e âmbito do Sprint · Previsões, incrementos e decisões de release
A ordenação deve tornar escolhas e hipóteses compreensíveis.
Referência: The Scrum Guide, November 2020 · PSPO I; Scrum Guide November 2020; no public numbered exam revision