D³
D³ Guide
The practical handbook for Decision-Driven Delivery.
01
Quick Start
Monday, 9 AM. Go.
Three steps to introduce Decision-Driven Delivery this week. No training, no certification, no tool setup.
01
Collect decisions
Sit down with your team for 30 minutes. Ask: "What open decisions are affecting what we build this week and next?" Write down every answer. Don't filter, don't evaluate. You'll be surprised how many there are — and how many nobody explicitly owns.
02
Create a Decision Map
Enter the decisions into a table. Five columns: Investigate, Decide, Implement, Validate, Learn. Each decision gets a row placed in the column matching its current state. That's your first Decision Map. A spreadsheet will do.
03
Complete one decision end-to-end
Pick the decision with the greatest strategic impact. Not the most urgent — the most important. Work it through all five modes. Depending on the topic, this takes a day to a week.
After that, you'll know if D³ works for your team. Not because you read about it, but because you did it.
02
The Decision Map
The central steering instrument.
The Decision Map replaces the Product Backlog. It doesn't show what's left to do — it shows what's left to decide and where each decision stands.
| Decision | Owner | Investigate | Decide | Implement | Validate | Learn |
|---|
| Authentication solution | M. Schmidt | ✓ | ✓ | ● | | |
| Cloud provider | E. Yilmaz | ✓ | ● | | | |
| Data migration strategy | — | ● | | | | |
| API versioning | T. Weber | ✓ | ✓ | ✓ | ✓ | ● |
| Monitoring stack | K. Braun | ✓ | ✓ | ✓ | ● | |
● = current phase · ✓ = completed · — = no owner assigned
Sort by impact, not urgency
Strategic decisions go on top. Tactical ones below. An undecided cloud provider blocks more than an open button label.
Maximum 15 active decisions
More than 15 entries means decisions are too granular or the team is spread too thin. Both are signals.
Every decision needs an owner
No owner means no decision. A "—" in the owner column is a warning, not a normal state.
Decisions reaching "Learn" leave the map
The map shows only active decisions. Completed ones move to an archive — relevant again during revisions.
03
Writing Decisions
The document worth more than a hundred tickets.
Every decision is captured as a standalone document. Not a side note in meeting minutes. Not a ticket comment. A structured document.
Decision Record
Title
Precise question, not answer.
What authentication solution for enterprise customers?
Status
Current mode.
Implement
Owner
Who owns this decision?
M. Schmidt (Tech Lead)
Context
Why is this decision needed?
Legacy system uses session-based auth. New requirement: SSO for enterprise customers with own IdP. Regulatory: MFA by Q3.
Options
Alternatives investigated?
A) Keycloak On-Prem — full control, higher ops overhead
B) Auth0 Managed — fast start, vendor lock-in
C) Custom Spring Security — max flexibility, highest risk
Decision
What was chosen and why?
Option A: Keycloak. Rationale: Regulatory requirements rule out cloud-only. Team has Keycloak experience from KBM project.
Rejected
What was not chosen and why?
Auth0: Data cannot reside in US cloud. Custom: Risk-benefit untenable given timeline.
Consequences
What follows?
Ops team must set up Keycloak cluster. Training for 2 devs. Migration path for existing users.
Revision trigger
When to revisit?
If regulations allow cloud hosting. If Keycloak ops costs > 3x Auth0 license costs.
Always write the title as a question. "Keycloak" is not a decision — "What authentication solution for enterprise customers?" is one.
04
The Five Modes
At the speed the decision requires.
Every decision passes through five modes. Tactical ones take hours. Strategic architecture decisions take one to two weeks. The rhythm follows decisions, not the calendar.
Explore the solution space. Identify options. Assess risks.
- —Research: What exists? What have others done?
- —Prototypes: PoC, spike, feasibility study
- —Use AI: Generate alternatives, analyze trade-offs
- —Interview stakeholders: Who is affected? What are constraints?
Output
Options document with at least two realistic alternatives.
Investigate doesn't end when someone has an opinion. It ends when options are documented.
Choose deliberately. Document. Own it.
- —The owner decides — not the committee
- —Write the Decision Record
- —Document rejected options — as important as the choice
- —Set a revision trigger: When do we revisit?
Output
Completed Decision Record.
A decision that isn't documented hasn't been made. It was only discussed.
Build what was decided, with focus.
- —Scope is clear: The decision defines what gets built
- —Use AI for code generation, boilerplate, tests
- —No scope creep: New questions → new decision on the map
- —Measure by outcome, not activity
Output
Implementation matching the decision.
If architecture gets "just quickly" changed mid-implementation, the decision wasn't properly made.
Measure outcome against decision.
- —Don't ask: "Is the ticket done?" Ask: "Does this deliver what the decision promised?"
- —Load tests, security review, fallback scenarios
- —Stakeholder feedback: Does this match expectations?
- —Tests that verify the decision — not just the code
Output
Result: passed / rework needed / reconsider decision.
"Works on my machine" is not validation.
Feed insights back. Archive.
- —What did we learn?
- —Does the assumption still hold?
- —What would we do differently?
- —Update Decision Record, move to archive
Output
Updated Decision Record in archive.
Skipping Learn because the next decision is pressing. That's exactly when you miss the most important insight.
05
Triage
Bug, gap, or wrong decision?
When something goes wrong, there are three possible causes. Triage distinguishes them because each requires a different response.
Bug
Was the decision implemented correctly?
No — implementation deviates from the decision.
Fix. Back to Implement. No new decision needed.
Keycloak configured but MFA enforcement missing in staging.
Gap
Was an aspect overlooked?
Yes — decision was right but incomplete.
Supplement. Extend Decision Record. Implement missing aspect.
Keycloak works but session timeout for enterprise customers wasn't specified.
Revision
Was the decision itself wrong?
Yes — assumptions turned out incorrect.
New decision. Back on map at Investigate. Archive old decision.
Keycloak ops costs 4x above estimate. Revision trigger hit.
Triage takes five minutes. Most teams skip it and treat everything as a bug. That's why the same problems recur.
06
Roles in Practice
What do these people actually do all day?
Three roles, defined by one question: Who makes which decisions?
Decision Owner
~ Product Owner
- —Monday: Review Decision Map — what's pending, what's overdue?
- —Tue–Thu: Provide context. Stakeholder conversations. Business perspective.
- —Friday: Validation Review — do outcomes match expectations?
Asks the right questions. Not "Build a login" but "How do enterprise customers authenticate securely?"
Decision Architect
~ Scrum Master
- —Monday: Check map status. Identify blockers. Spot dependencies.
- —Daily: Steer the decision process. Ensure decisions aren't delayed or rushed.
- —Friday: Review Decision Records for completeness. Maintain archive.
Protects the process. If a decision's been stuck in Investigate for three weeks, that's their problem.
Decision Maker
~ Developer
- —Monday: Review current decisions. Understand the solution space.
- —Tue–Thu: Investigate, decide, implement, validate. Use AI tools.
- —Friday: Document learnings. Update Decision Records.
Core contribution isn't code — it's decision competence. AI tools are instruments, not replacements.
07
Rituals
Three fixed meetings. No more.
D³ has fewer rituals than Scrum. No daily, no sprint planning, no separate retrospective.
Map Review
Mondays · 30 min
Decision Owner + Architect
- —What decisions are new?
- —Which are blocked?
- —Which have no owner?
- —Is priority order correct?
Updated Decision Map.
Validation Review
Fridays · 45 min
All three roles
- —Which decisions were validated?
- —Do outcomes match?
- —What did we learn?
- —Revision needed?
Validated → archive. Learnings → documented. Revisions → map.
Architect + Decision Maker
- —Bug, gap, or revision?
- —Immediate assignment
Clear next action.
08
AI in the Workflow
The "how", not the "whether".
AI tools change what a single developer can accomplish — and with it, what a decision costs and how quickly it's implemented.
Investigate
Generate alternatives. Build prototypes. Trade-off analysis.
"Compare Keycloak, Auth0, and custom build by cost, vendor lock-in, and compliance."
Decide
Draft Decision Records. Consequence analysis.
"Summarize PoC results and draft a Decision Record with consequences and revision trigger."
Implement
Code generation. Boilerplate. Test scaffolding.
"Implement Keycloak integration per Decision Record. Spring Boot, MFA enforcement."
Validate
Test generation. Security scans. Load simulations.
"Generate integration tests: MFA enforced, 30-min session timeout, enterprise SSO."
Learn
Summarize learnings. Identify patterns.
"Analyze the last five decisions. What patterns in revision triggers?"
AI accelerates every mode. But it doesn't make decisions. Responsibility stays with people.
09
Metrics
What to measure — and what not to.
D³ doesn't measure how much the team accomplished. It measures how well the team decided.
Decision Cycle Time
How long from Investigate to Learn? Shorter = faster learning.
Decision Backlog Age
How many decisions open > 2 weeks? Rising = decision gridlock.
Owner Coverage
% of decisions with clear owner. Below 100% = warning.
Revision Rate
10–20% is healthy. Zero = nobody checks. 30%+ = Investigate too thin.
Velocity / Story Points
Measures activity, not outcome.
Lines of Code
Meaningless in the AI era.
Decisions per week
Encourages quantity over quality.
10
Migrating from Scrum
No big bang. Four weeks.
D³ doesn't replace Scrum overnight. Migration works as a gradual transition parallel to the existing process.
Week 1
Make decisions visible
- —Create first Decision Map alongside backlog
- —Identify open decisions disguised as tickets
- —Assign roles: Who is Owner, who is Architect?
Week 2
Complete first decisions
- —Work 2–3 decisions through all five modes
- —Write first Decision Records
- —Add Decision Review to Sprint Review
- —Decision Map becomes primary steering instrument
- —Tickets remain for implementation, prioritization from map
- —First triage: bug, gap, or revision?
Week 4
Replace Scrum rituals
- —Sprint Planning → Map Review (Monday)
- —Sprint Review → Validation Review (Friday)
- —Daily standup → optional
- —Retrospective → integrated into Validation Review
After four weeks, you decide: Does D³ work better than what came before? The answer is in the Decision Map.