APRENDER. PRATICAR. EVOLUIR.Separar condições de preferências
No exercício fictício Dália, há seis dias-pessoa disponíveis. A correção M custa dois e é uma condição já aprovada para manter o serviço nesta janela. As restantes opções são A, com custo três e benefício oito; B, com custo quatro e benefício onze; C, com custo dois e benefício sete; e D, com custo um e benefício quatro. D depende de A. Cada item só pode ser escolhido uma vez. Os benefícios são unidades didáticas aditivas, não euros nem resultados já observados. Começa por respeitar M e a dependência. M+A+D usa seis dias-pessoa e oferece doze unidades; M+B usa seis e oferece onze; M+C usa quatro e oferece sete. M+C+D parece atraente, mas falta A. Uma tabela de prioridades precisa de tornar estas condições visíveis. Se M deixar de fazer sentido, procura a autoridade que pode rever a condição e apresenta a evidência. A pontuação do Product Owner não altera essa decisão por si só.
Uma fórmula tem pressupostos
No segundo exercício, a fórmula local é benefício estimado × confiança ÷ esforço. A recebe 40 × 0,5 ÷ 4 = 5; B recebe 18 × 0,9 ÷ 3 = 5,4. A ordem muda se a confiança em A passar a 0,8: o resultado torna-se oito. Regista de onde veio cada estimativa e a evidência que justificaria alterá-la. Uma preferência do sponsor pode ser um contributo, mas não demonstra probabilidade de benefício. Decide se vale a pena investigar a incerteza antes do compromisso. A fórmula é um instrumento deste exercício, não uma regra obrigatória de Scrum. Considera também interações: se uma melhoria remove seis horas semanais e outra quatro, com duas horas de trabalho em comum, a poupança conjunta é oito, não dez. Não somes benefícios sobrepostos. Um esforço de quarenta dias já gasto também não passa a ser benefício futuro; compara custos futuros, alternativas e consequências de continuar ou parar.
Da combinação ao plano de trabalho
A melhor combinação do modelo Dália ainda não é uma promessa de entrega. O modelo ignora competências, calendário, variabilidade e outras interações. Dois especialistas durante três dias simultâneos representam seis dias-pessoa de esforço e três dias de duração. É necessário confirmar a sua disponibilidade e a sequência técnica. Os Developers continuam responsáveis por dimensionar o trabalho que irão realizar; uma otimização não substitui esse conhecimento. Se o fornecedor prevê um ambiente no dia doze sem confirmação, apresenta a dependência e o próximo ponto de revisão no roadmap. Comunica a intenção, o trabalho adiado e o que justificaria reconsiderar a ordem. Inclui manutenção e apoio à operação quando contribuem para o resultado pretendido. Neste exercício, nenhuma combinação autoriza uma mudança de produção nem altera políticas bancárias. A análise dá uma recomendação sob condições explícitas, que deve evoluir com a aprendizagem e com as decisões de quem tem o mandato necessário.
Oficina Dália de trinta minutos
Reúne Product Owner, Developers, APS, sponsor e observador para um ensaio com a tabela apresentada. Dedica cinco minutos ao objetivo e às condições, dez à comparação de combinações, dez à discussão de incerteza e cinco ao debrief. Pede ao grupo que explique por que razão a melhor relação individual benefício/esforço não garante a melhor combinação. Depois introduz a indisponibilidade de uma competência necessária a A. Os seis dias-pessoa, por si só, deixaram de demonstrar viabilidade real; o grupo deve pedir informação e rever o plano, sem alterar silenciosamente a estimativa. Entrega uma folha com opções, dependências, recomendação, pressupostos e próxima decisão. O observador regista se as condições foram respeitadas, se a equipa distinguiu cálculo de compromisso e se comunicou o trabalho adiado. Usa os estados “não observado”, “observado com ajuda” e “observado no ensaio sem ajuda”. Não há classificação profissional atribuída. O guião foi preparado, mas não foi executado com participantes humanos.
GUIÃO DÁLIA | 30 min: 5 + 10 + 10 + 5
Item | esforço | benefício | condição
M | 2 | 0 | obrigatório
A | 3 | 8 | sem dependência
B | 4 | 11 | sem dependência
C | 2 | 7 | sem dependência
D | 1 | 4 | requer A
Capacidade: 6 dias-pessoa; itens únicos; benefícios aditivos.
Objetivo:
Combinações válidas / esforço / benefício:
Combinações excluídas / razão:
Competências e calendário por confirmar:
Hipóteses e origem das estimativas:
Recomendação / trabalho adiado:
Evidência que mudaria a ordem:
Próxima decisão / responsável / data:
Observação: não observado | com ajuda | no ensaio sem ajudaM+A+D oferece doze unidades no modelo; M+B oferece onze. A recomendação depende de a competência necessária a A estar disponível.
Armadilhas comuns
Ordenar itens sem dependências; confundir esforço com calendário; somar benefícios sobrepostos; usar confiança sem origem; prometer o ótimo do modelo.
Tópicos relacionados: Ordenação do Product Backlog · Descoberta e evidência · Roadmaps e dependências
Uma prioridade defensável combina objetivo, condições, opções viáveis e pressupostos que podem ser revistos.
Referência: Deciding on priorities · Scrum Guide November2020; EBM May2024; primary product practice reviewed 2026-09-30