Conceito e mecanismo
Ordenar trabalho exige escolhas. Dividir sempre capacidade igualmente entre stakeholders pode parecer justo, mas não demonstra maior contribuição para o objetivo. Explica valor esperado, dependências, restrições e razões da decisão, mantendo abertura a informação nova. O Product Owner pode dizer que um pedido não será tratado agora sem impedir colaboração futura. Tamanho também não determina prioridade por si. Um item pequeno pode desbloquear aprendizagem importante, mas nem todo o item pequeno merece vir primeiro. Compara contribuição e custo no contexto. Não transformes uma técnica de priorização numa fórmula que substitui julgamento e responsabilidade pelo produto.
Aplicação guiada
Uma condição de aceitação obrigatória e uma janela fixa exigem uma conversa explícita sobre capacidade. Acrescentar um extra não aumenta a capacidade disponível. Protege o compromisso necessário e negocia alternativas, faseamento ou recursos através das autoridades adequadas. Inclui trabalho técnico que afeta qualidade e capacidade futura: regressões recorrentes podem consumir tempo que faria falta para responder a utilizadores. Esse investimento precisa de propósito e evidência, tal como uma funcionalidade. Quando nova informação reduz o valor de algo quase terminado, compara custos restantes e benefícios alcançáveis. Os 80% já desenvolvidos são contexto, mas não constituem uma razão suficiente para gastar os 20% finais se existir uma alternativa melhor.
Uma melhoria que reduz retrabalho pode ter valor através de capacidade futura, mesmo que não acrescente um botão visível.
Armadilhas comuns
Pressão como prioridade; custo passado como justificação; técnico como trabalho sem valor; promessa sem capacidade.
Tópicos relacionados: Previsões, fluxo e escolhas de release · EBM e interpretação de medidas
Ordena com razões explícitas e revê quando a evidência muda.
Referência: Introduction to the Product Backlog · PSPO II; Scrum Guide November 2020 and EBM Guide May 2024; no public numbered exam revision