Separate conditions from preferences
In the fictional Dahlia exercise, six person-days are available. Fix M costs two and is an already approved condition for keeping the service running in this window. The remaining options are A, costing three with benefit eight; B, costing four with benefit eleven; C, costing two with benefit seven; and D, costing one with benefit four. D depends on A. Each item can be chosen only once. Benefits are additive teaching units, not euros or already observed outcomes. Start by respecting M and the dependency. M+A+D uses six person-days and offers twelve units; M+B uses six and offers eleven; M+C uses four and offers seven. M+C+D looks attractive, but A is missing. A priorities table needs to expose these conditions. If M no longer makes sense, approach the authority able to revise the condition and present the evidence. The Product Owner’s score does not itself change that decision.
A formula has assumptions
In the second exercise, the local formula is estimated benefit × confidence ÷ effort. A receives 40 × 0.5 ÷ 4 = 5; B receives 18 × 0.9 ÷ 3 = 5.4. Ordering changes if confidence in A becomes 0.8: its result becomes eight. Record where each estimate came from and what evidence would justify changing it. A sponsor’s preference can be input, but does not demonstrate a probability of benefit. Decide whether investigating uncertainty is worthwhile before commitment. The formula is a tool for this exercise, not a mandatory Scrum rule. Also consider interactions: if one improvement removes six weekly hours and another four, with two hours of shared work, the combined saving is eight, not ten. Do not add overlapping benefits. Forty days of effort already spent do not become future benefit either; compare future costs, alternatives, and consequences of continuing or stopping.
From a bundle to a work plan
The best bundle in the Dahlia model is still not a delivery promise. The model omits skills, calendar, variability, and other interactions. Two specialists working simultaneously for three days represent six person-days of effort and three days of duration. Their availability and the technical sequence need confirmation. Developers remain responsible for sizing the work they will perform; optimization does not replace that knowledge. If the supplier forecasts an environment on day twelve without confirmation, show the dependency and next review point on the roadmap. Communicate intent, deferred work, and what would justify reconsidering the order. Include maintenance and operational support when they contribute to the intended outcome. In this exercise, no bundle authorizes a production change or alters banking policies. Analysis provides a recommendation under explicit conditions that should evolve with learning and decisions from those holding the necessary mandate.
Thirty-minute Dahlia workshop
Gather a Product Owner, Developers, APS, sponsor, and observer for a rehearsal using the supplied table. Spend five minutes on the goal and conditions, ten comparing bundles, ten discussing uncertainty, and five on debrief. Ask the group to explain why the best individual benefit-to-effort ratio does not guarantee the best bundle. Then introduce the unavailability of a skill needed for A. Six person-days alone no longer demonstrate real feasibility; the group should request information and revise the plan without silently changing the estimate. Produce a sheet with options, dependencies, recommendation, assumptions, and next decision. The observer records whether conditions were respected, whether the team distinguished calculation from commitment, and whether it communicated deferred work. Use “not observed,” “observed with help,” and “observed in rehearsal without help.” No professional rating is awarded. The guide is prepared but has not been executed with human participants.
DAHLIA GUIDE | 30 min: 5 + 10 + 10 + 5
Item | effort | benefit | condition
M | 2 | 0 | required
A | 3 | 8 | no dependency
B | 4 | 11 | no dependency
C | 2 | 7 | no dependency
D | 1 | 4 | requires A
Capacity: 6 person-days; unique items; additive benefits.
Goal:
Valid bundles / effort / benefit:
Excluded bundles / reason:
Skills and calendar to confirm:
Assumptions and estimate provenance:
Recommendation / deferred work:
Evidence that would change ordering:
Next decision / owner / date:
Observation: not observed | with help | in rehearsal without helpM+A+D offers twelve units in the model; M+B offers eleven. The recommendation depends on the skill needed for A being available.
Common pitfalls
Rank items without dependencies; confuse effort with calendar time; add overlapping benefits; use confidence without provenance; promise the model optimum.
Related topics: Product Backlog ordering · Discovery and evidence · Roadmaps and dependencies
A defensible priority combines a goal, conditions, feasible options, and assumptions open to revision.
Reference: Deciding on priorities · Scrum Guide November2020; EBM May2024; primary product practice reviewed 2026-09-30