How to Implement DSDM: A Step-by-Step Guide

This guide takes you from “we’ve decided to use DSDM” to a project that is delivering in timeboxes against a fixed date. It assumes you know what DSDM is and why you’d choose it; if you don’t, read DSDM explained first and come back. Here we only cover the doing: who to put in which role, what to produce in each phase, the templates to copy, and the mistakes that sink most first attempts.

One scenario runs through every step. A mid-sized insurer has to launch an online claims portal before a regulatory deadline nine months away. The date can’t move, the budget is approved, and the business has a long list of features it calls “essential”. That is exactly the situation DSDM was built for.

Who this is for

• Project managers and delivery leads who’ve been asked to run a project “the DSDM way” or are preparing for AgilePM in practice.
• Scrum Masters and team leads moving onto a fixed-deadline project where sprint-by-sprint scope drift won’t be tolerated.
• Sponsors who want to know what they’re signing up for before they agree to it.

Before you start

You need three things in place before Step 1 is worth doing:

1. A deadline that is genuinely fixed. Regulatory, contractual or a public launch. If the date is really a target that could slip a month, DSDM’s discipline will feel like theatre and people will stop respecting it.
2. A sponsor who will make scope decisions. Not approve a plan, but personally decide what gets dropped when time runs short.
3. Someone from the business who can spend real time with the team. This becomes your Business Ambassador. If the best you can get is an hour a fortnight, stop here; DSDM won’t work.

Step 1: Check that DSDM fits this project

DSDM has a formal tool for this, the Project Approach Questionnaire. Use the simplified version in the templates below. Run it with the sponsor and the likely project manager in one meeting, and be honest: every “no” is a risk you either fix now or accept in writing.

In the scenario: the claims portal scores well on the deadline, the sponsor and the funding. It scores badly on business availability: the claims operations lead who knows the process is already over-committed. That’s the one “no” that matters, and the sponsor agrees to backfill two days a week of her time before the project starts. Without that agreement, this guide would end here.

Step 2: Staff the roles that actually matter

DSDM defines a lot of roles. On a first project, get these right and combine the rest:

Role	What they must be able to do	Common mistake
Business Sponsor	Own the budget and the business case; break deadlocks on scope	A committee instead of one person
Business Visionary	Hold the picture of what the business needs and interpret it for the team	Given to whoever wrote the requirements document
Business Ambassador	Make day-to-day decisions on requirements and priority, inside the team	A junior analyst with no authority
Technical Coordinator	Own technical quality and architecture across timeboxes	Left vacant “because the developers will handle it”
Project Manager	Plan increments, manage risk, protect the timeboxes	Acting as the scope decision-maker
Team Leader	Run the timebox day to day with the Solution Development Team	The project manager doing this as a second job

The Business Ambassador is the role that decides whether DSDM works. They sit with the team, answer questions the same day, and say “that’s a Could” without needing a meeting. I’d plan for at least two days a week from them; less than that and the team starts guessing, which is how Musts quietly get built wrong.

In the scenario: the Head of Claims is Business Visionary, the backfilled claims operations lead is Business Ambassador, and the Chief Operating Officer is Business Sponsor. One person, with the final say.

Step 3: Run Feasibility in days, not weeks

Feasibility answers one question: can this be delivered in the time and money available, at all? It is not the place to collect requirements. Produce three things:

• A one-page outline business case: the problem, the deadline and why it is fixed, the budget, and what happens if nothing is delivered.
• A first-cut list of capabilities (ten to twenty lines, not hundreds of stories).
• A rough view of whether the essentials fit inside the date, with the biggest risks named.

If Feasibility shows the essentials can’t fit, that is a success. You’ve found out in a week instead of month seven.

In the scenario: Feasibility takes four days. The capability list has 14 lines. The team’s rough sizing says the regulatory essentials (submit a claim online, upload evidence, track status, accessibility compliance) fit comfortably; the business’s wider wish list does not.

Step 4: Run Foundations and build the prioritised requirements list

Time-box Foundations itself and make it answer the four questions in DSDM explained: minimum scope, who decides, what done means, and the fixed constraints. Write each answer on one page that the sponsor signs. If you find yourself writing detailed specifications, stop: detail only as far as you need to estimate.

The main output is the prioritised requirements list: every requirement, its MoSCoW priority, its estimated effort and who in the business owns it. The rule that makes DSDM work is about effort, not count: Must-haves should be no more than about 60% of the total estimated effort. The Shoulds and Coulds are your contingency. If Musts are 90% of the effort, you have no room to absorb the surprises every project has, and you’ll miss the date.

In the scenario: the first draft has 41 requirements and the business has marked 33 as Must, about 85% of the effort. The Business Visionary and Ambassador go through them line by line with one question: “If we launch without this, are we non-compliant or unable to process claims?” After two sessions, Musts are 58% of the effort. Live chat, an insurer-branded mobile app and saved drafts move to Should and Could.

Step 5: Plan increments and timeboxes

Split the time to the deadline into increments (releases the business could actually use) and each increment into timeboxes of two to four weeks. Every timebox gets a clear objective and its own small MoSCoW list taken from the project’s list.

Inside each timebox, DSDM’s structured timebox gives you a rhythm:

1. Kick-off: agree the objective and the timebox’s priorities.
2. Investigation: explore the detail of each requirement with the Ambassador.
3. Refinement: build, test and review, iteratively.
4. Consolidation: finish, tidy and confirm what’s done.
5. Close-out: formal review of what was delivered against the objective.

Never extend a timebox. When it ends, it ends; unfinished work goes back to the list and is reprioritised.

In the scenario: nine months becomes three increments. Increment 1 (submit a claim, upload evidence and track its status) is five two-week timeboxes, giving a private beta at month three. Increments 2 and 3 add the document scanner integration, accessibility hardening and the remaining Should-haves, with a four-week buffer before the regulatory date.

Step 6: Run Evolutionary Development

This is where DSDM looks most like other Agile frameworks: a daily stand-up, short feedback loops, working software demonstrated at the end of every timebox. The DSDM-specific disciplines to hold onto are:

• Facilitated workshops for decisions. When a requirement is contentious, get the Visionary, Ambassador and developers in a room with a neutral facilitator and leave with a decision, not actions.
• Test as you go. “Never compromise quality” is a DSDM principle; quality is fixed along with time and cost. Testing in a final phase is how teams end up trading quality for the date without admitting it.
• Demonstrate control. Report progress as working, accepted features, not percentages complete.

In the scenario: in timebox 3, the claims team and the fraud team disagree about how much evidence a customer must upload before submitting. A two-hour facilitated workshop settles it: minimum evidence at submission, the rest requested later. Without that workshop, the argument would have run for three timeboxes in email.

Step 7: Protect the date when things slip

Something will slip. When a timebox is running late, apply the rules in this order:

1. Drop Could-haves from the timebox.
2. Drop Should-haves, with the Ambassador’s agreement.
3. If a Must-have is at risk, escalate to the Business Sponsor the same day. This is the only escalation that should ever reach them, and it is why the 60% rule exists.

What you never do: extend the timebox, quietly cut testing, or move the deadline.

In the scenario: in increment 2 a third-party document scanner integration takes twice the estimate. The team drops two Could-haves and one Should-have (text-message status updates) from that increment. No Must is at risk, so the sponsor hears about it in the timebox review, not as a crisis.

Step 8: Deploy and check the benefits

Deployment in DSDM happens at the end of every increment, not only at the end of the project. Each deployment includes the business change, not just the software: trained staff, updated processes and support in place.

After the final increment, the Post-Project phase asks whether the business case was delivered. Book that review before the project closes, or it will never happen.

In the scenario: the portal goes live four weeks before the regulatory date. Three months later the benefits review shows online claims at 40% of volume and call-centre claim calls down. The deferred Could-haves are reviewed: two are still wanted and go into the next budget cycle, the rest are dropped.

Copy-paste templates

Readiness checklist (simplified from DSDM’s Project Approach Questionnaire)

DSDM readiness check (answer yes / no / partly; every "no" needs an owner and an action)

[ ] The deadline is genuinely fixed, and we can say why
[ ] One named Business Sponsor will make scope decisions personally
[ ] A Business Ambassador with authority is available 2+ days a week
[ ] The business accepts that not every requirement will be delivered
[ ] Requirements can be prioritised and delivered incrementally
[ ] The team can be co-located or works well remotely, with daily contact
[ ] The organisation will accept working software as progress, not documents
[ ] Quality criteria (testing, accessibility, security) are agreed up front
[ ] Governance will review at increment boundaries, not demand a full upfront spec

Prioritised requirements list

| ID  | Requirement                          | MoSCoW | Effort (days) | Business owner     | Why this priority                      |
|-----|--------------------------------------|--------|---------------|--------------------|----------------------------------------|
| R01 | Customer can submit a claim online   | Must   | 18            | Claims ops lead    | Regulatory requirement                 |
| R02 | Customer can track claim status      | Must   | 10            | Claims ops lead    | Regulatory requirement                 |
| R03 | Upload photos and documents          | Must   | 12            | Head of Claims     | Claims can't be assessed without it    |
| R04 | Save a claim as a draft              | Should | 6             | Digital product    | Reduces abandonment, not required      |
| R05 | Live chat with a claims handler      | Could  | 15            | Customer service   | Nice to have; phone covers the need    |
| R06 | Native mobile app                    | Won't  | -             | Digital product    | Not this time; revisit after launch    |

Effort check
  Must total:   40 days
  All total:    61 days (excluding Won't)
  Must share:   40 / 61 = 66%  -> over 60%: reprioritise or rescope before planning

Timebox plan

| Timebox | Dates          | Objective                              | Must           | Should / Could | Review with           |
|---------|----------------|----------------------------------------|----------------|----------------|-----------------------|
| TB1     | 4-15 Jan       | Customer can start and submit a claim  | R01            | -              | Ambassador, Visionary |
| TB2     | 18-29 Jan      | Customer can see claim status          | R02            | R04 (Should)   | Ambassador            |
| TB3     | 1-12 Feb       | Evidence upload, first version         | R03            | R05 (Could)    | Ambassador, Fraud lead|

Rules: no timebox is extended; unfinished items return to the list and are reprioritised.

Common mistakes

The junior Ambassador. The Ambassador role goes to whoever is free, not whoever can decide. Every question becomes a meeting and the team guesses in the meantime. Fix: make the sponsor choose the Ambassador by asking “who would you trust to drop a feature without asking you?”

Everything is a Must. If Musts are 80% or more of the effort, you’ve rebuilt waterfall with Agile vocabulary. Fix: apply the effort check from the template and refuse to plan timeboxes until Musts are at or under about 60%.

Foundations as a requirements phase. Three months of detailed specification before any building starts. Fix: time-box Foundations itself (about two weeks for a medium project) and only detail requirements as far as you need to estimate them.

Extending the timebox “just this once”. It’s never once. Fix: end on the date, reprioritise what’s left, and treat the slip as information about your estimates.

Testing at the end. Quality gets traded for the date in the final weeks, silently. Fix: no requirement counts as done until it’s tested and accepted inside its timebox.

No benefits review. The project closes and nobody checks whether the business case was met. Fix: book the Post-Project review date during Foundations.

You’re done when

• The readiness checklist has no unowned “no” answers
• One named Business Sponsor and an Ambassador with authority are in place
• Feasibility produced an outline business case and a short capability list
• The prioritised requirements list exists, with Musts at or under about 60% of effort
• Increments and two-to-four-week timeboxes are planned up to the deadline
• Every timebox has an objective, its own MoSCoW list and a fixed end date
• Slips are handled by dropping Coulds, then Shoulds, then escalating, never by extending
• A Post-Project benefits review is booked