Imagine hiring an architecture firm to build your house. Every two weeks, they send you a report: 47 bricks laid this week, 23 meters of pipe installed, velocity at 94%. Impressive numbers.
But nobody asked whether the house needs a basement. Whether the kitchen should face south. Whether the floor plan actually fits your family.
That’s what happens in most software projects.
What Scrum measures — and what it misses
Scrum was designed over twenty years ago. It solved a real problem: software projects that disappeared into the dark for years and delivered the wrong thing. Scrum introduced rhythm, transparency, and regular feedback. That was progress.
But Scrum measures a project’s progress by the volume of completed tasks. Tickets, story points, velocity. That works as long as writing software is the bottleneck — as long as the question is: Are we building fast enough?
Today, the question is different. AI can produce in hours what used to take a team weeks. Code production is no longer scarce. What’s scarce: the ability to make the right decisions.
Which architecture will hold up long-term? Which technology fits our constraints? Which requirement is truly business-critical, and which one is just loud?
No sprint planning answers these questions.
Flipping the lens
Every software project is, at its core, a chain of decisions: Which database do we use? How do users authenticate? Should the system work synchronously or asynchronously? Build or buy?
Each decision has consequences. It opens doors and closes others. It costs money when it’s wrong, and even more money when it’s late.
Scrum treats all of these equally: entries in a backlog, processed in two-week cycles. The strategic architecture decision sits next to the bug fix and the UI polish. The question of whether authentication is fundamentally sound competes with the question of whether a button is the right color.
What if you separated those? What if you gave what actually matters — the decisions — their own layer of governance?
That’s the idea behind Decision-Driven Delivery.
Instead of asking “How much did we get done?” it asks: “Which decisions did we make — and were they the right ones?”
Five modes, not a two-week clock
A team working with Decision-Driven Delivery moves through five modes. Not sequentially like waterfall, but in fast cycles — per decision.
Explore. Before making a decision, the solution space is investigated. What are the options? What speaks for each, what against? What are the risks? This is where AI tools shine: generating prototypes, testing feasibility, comparing alternatives. The output isn’t code — it’s clarity.
Decide. The decision is made deliberately, documented, and owned. Not as a side note in meeting minutes, but as a standalone record: What was decided? What was rejected, and why? Under what circumstances should this decision be revisited? This document is worth more than a hundred tickets.
Execute. Now you build — focused on what was decided. No scope creep, no detours. AI tools accelerate implementation significantly. The team focuses on ensuring the quality of the outcome.
Validate. Does the result deliver what the decision promised? Not: Is the ticket done? But: Does authentication hold under load? Is the fallback tested? Can we roll back if something breaks?
Learn. What did we learn about this decision? Does the assumption still hold? Does something need correcting? The insight feeds back and influences future decisions.
These five steps aren’t waterfall. For a tactical decision, they might take hours. For a strategic architecture decision, maybe one to two weeks. The difference from Scrum: the rhythm follows the decision landscape, not the calendar.
What actually changes
| Scrum | Decision-Driven Delivery | |
|---|---|---|
| What’s governed? | Tasks (tickets in a sprint) | Decisions (on the Decision Map) |
| Progress | Velocity, story points, burndown | Decision quality, cycle time per outcome |
| Every two weeks | Sprint review: What got done? | Validation review: Do outcomes match expectations? |
| Prioritization | Product backlog, sorted by PO | Decision Map: strategic decisions before tactical |
| Hotfix | Sprint goal at risk, velocity drops | Triage: Bug, implementation gap, or signal that a decision was wrong? |
| AI | Not part of the framework | Integral: accelerates exploration and execution |
| Documentation | Ticket history | Decisions, alternatives, consequences, revision conditions |
| Billing | Day rates, time-based | Fixed price per outcome |
Three roles, one question: Who decides?
Scrum has three roles: Product Owner, Scrum Master, Developer. Decision-Driven Delivery defines roles through a different question: Who makes which decisions?
Decision Owner. Similar to the Product Owner, but with a different focus. They don’t say “Build a login form.” They ask “How do our enterprise clients authenticate securely and conveniently?” They connect the business perspective with technical reality and own the prioritization: Which decision has the greatest strategic weight?
Decision Architect. Similar to the Scrum Master, but instead of facilitating rituals, they govern the decision process. They ensure decisions are neither stalled nor rushed. They recognize dependencies, protect the team from overload, and make sure every decision is properly documented.
Decision Maker. The specialists — developers, architects, engineers. Their core contribution isn’t code, it’s decision competence. They investigate the solution space, prepare technical decisions, make architecture calls autonomously, and implement them. AI tools are their instrument — not their replacement.
The Decision Map
In Scrum, the central governance instrument is the Product Backlog: a priority-sorted list of tasks. In Decision-Driven Delivery, it’s the Decision Map.
The Decision Map shows at a glance: Which decisions are pending? Which are being explored, which are decided, which are implemented and validated? Where are the dependencies? What’s blocking?
The central governance question shifts. Instead of “How many story points did we complete?” it becomes: “Which strategic decisions are open, and what’s missing to make them?”
For leadership, this has a crucial side effect: the Decision Map makes the actual state of a project visible. Not in abstract velocity curves, but in concrete questions: Has the architecture decision been made? Is the compliance question resolved? Are we waiting on a board decision?
The daily reality: Unplanned work
One of the most common pain points in Scrum is dealing with disruptions. A sprint gets planned, then a hotfix comes in, QA reports bugs, a client escalates. By Friday, the sprint goal is missed.
This happens because the sprint is the only container Scrum knows. There’s no structural distinction between a strategic architecture decision and a broken layout.
Decision-Driven Delivery classifies unplanned work by its actual character:
Level 1 — Simple fix. A clearly identified bug with a known cause. Fixed directly, without touching the decision process.
Level 2 — Implementation gap. The outcome doesn’t fully satisfy the underlying decision. The implementation is adjusted — within the existing framework.
Level 3 — Revision signal. Recurring problems in the same area. This isn’t a bug anymore — it’s a signal that a decision needs to be revisited. A new exploration is initiated.
This distinction prevents two things: teams silently rewriting architecture under the cover of a bugfix, and real warning signals being dismissed as “just another bug.”
AI isn’t a tool on the side
In Decision-Driven Delivery, AI isn’t an optional add-on — it’s integral. But not as a replacement for human decisions. As an amplifier.
During exploration, AI generates prototypes, compares alternatives, and compresses the information space. During execution, AI writes code, tests, and documentation — faster than any human team. During validation, AI detects patterns that signal problems.
What AI cannot do: take responsibility for a decision. When an AI tool suggests an architecture and that architecture collapses under load, the AI isn’t liable. The decision to follow that recommendation sits with a human — and is documented as such.
What it means for clients
Decision-Driven Delivery also changes how software projects are commissioned and billed. The classic model — day rates for developers, billed by effort — creates a misaligned incentive: the longer a project takes, the more the vendor earns.
Phase 1: Create clarity. In one to two weeks, all strategic decisions for an initiative are made and documented. The client receives a complete decision landscape with architecture recommendation. Fixed price. After that, they can continue with any partner — or internally.
Phase 2: Deliver outcomes. Implementation isn’t billed by effort, but per concrete outcome. Not “200 developer hours,” but “authentication layer with SSO integration.” Whether the vendor delivers in three days or three weeks is their business.
Phase 3: Advise. Strategic consulting on demand, cancelable monthly. Architecture reviews, decision audits, early warning system for problems.
A core principle: The client can replace the vendor at any time. Every document, every decision, every line of code belongs to the client. Loyalty is earned through quality, not dependency.
What it isn’t
Not waterfall. The five modes alternate rapidly. No months-long planning phase before building.
Not all-or-nothing. Teams can adopt Decision-Driven Delivery incrementally. A good start: use the Decision Map alongside your existing backlog.
Not anti-Scrum. Teams can still use Kanban, pair programming, or other methods during execution. Decision-Driven Delivery governs what gets built and why. Not how.
How to start
If you recognize the problems described here, there’s one simple first step: Write down the five most important open decisions in your current project. Not tasks. Not features. Decisions.
Then ask yourself for each: Who’s responsible? What information is missing to make it? What’s blocked as long as it remains open?
You’ll probably find that at least one of these decisions has been open for weeks, that nobody is clearly responsible, and that your project is slower than it should be for exactly that reason.
That’s where Decision-Driven Delivery begins.
The D³ Guide walks you through the entire framework step by step — from Quick Start to Decision Records, roles, rituals, and metrics.
Decision-Driven Delivery is an open framework by Entwicklerherz. The full specification with schemas, templates, and conformance suite will be published on GitHub soon.