Decision Fields and DACI
Good decisions are easy to revisit because fields are filled consistently.
Decision fields explained
| Field | Why it matters | Guidance |
|---|---|---|
| Title | Makes decisions discoverable | Start with an action verb (Adopt, Delay, Remove) |
| Status | Shows lifecycle stage | Use your team’s status conventions in the app |
| Decision Date | Creates timeline clarity | Use the date the decision was made, not when it was logged |
| Rationale | Preserves context | Explain tradeoffs and the reason this option was chosen |
| Linked Issues | Connects decision to execution | Link the stories/tasks that implement the decision |
| Category | Supports reporting and filtering | Use a stable set (Architecture, Process, Product, Ops) |
DACI roles
DACI clarifies ownership and involvement:
- Driver: owns the process and keeps momentum
- Approver: makes final call
- Contributors: provide input and expertise
- Informed: need visibility but do not decide
DACI example
For a decision to deprecate an API version:
| DACI Role | Example |
|---|---|
| Driver | API Product Manager |
| Approver | Head of Engineering |
| Contributors | Backend Lead, Support Lead |
| Informed | Customer Success, QA |
Best practices
- Assign exactly one Approver for clarity
- Keep Contributors focused; avoid listing entire departments
- Use Informed for downstream teams affected by rollout
- Review DACI assignments during planning if scope changes