DSDM

When to Use
• For larger corporate organisations with a complex architecture and/or
governance standards, agreeing the foundations early in the project is
essential
• IT and Non-IT projects
▪ Inappropriate projects
 real time
 safety critical
 have well defined requirements
 have no fixed end date
 re-usable components
▪ Appropriate projects
 prioritisable requirements
 fixed end date
 clearly defined users
 can be broken down
Dynamic Systems Development Method
• Created by group of British firms in 1993
• 15 practices, 12 roles, and 23 work products
• Non-proprietary RAD approach from the early 1990s
• Applies a framework for RAD and short time frames
• Paradigm is the 80/20 rule
• majority of the requirements can be delivered in a relatively short amount of time.

3/6/2025
DSDM Principles
1. Active user involvement imperative (Ambassador users)
2. DSDM teams empowered to make decisions
3. Focus on frequent product delivery
4. Product acceptance is fitness for business purpose
5. Iterative and incremental development - to converge on a solution
6. Requirements initially agreed at a high level
7. All changes made during development are reversible
8. Testing is integrated throughout the life cycle
9. Collaborative and co-operative approach among all stakeholders essential

Time-to-market and delivery on-time at all times are key

3/6/2025 values and principles in DSDM
DSDM Lifecycle
• Pre-project
• Feasibility study
• Business study – prioritized requirements
• Functional model iteration
• risk analysis
• Time-box plan
• Design and build iteration
• Implementation
• Post-project
3/6/2025
 In this phase, the users are
Only if the RAD is found as a
trained, and the system is put
justified approach for the desired
into the operational
system, the development
environment.
continues.

The end product of this phase is a

functional model consisting of an analysis
software components designed during
model and some software components
the functional modeling are further
containing significant functionality.
refined
The two phases, as a result, may
simultaneously continue. The product
of this phase is a tested system ready
for implementation.
3/6/2025
Implementation
• At the end of this phase, there are four possibilities, as depicted:
• Everything was delivered as per the user demand, so no further development
is required.
• A new functional area was discovered, so return to the business study phase
and repeat the whole process.
• A less essential part of the project was missed out due to time constraints.
So development returns to the functional model iteration.
• Some non-functional requirements were not satisfied, so the development
returns to the design and build phase.
Atern
• Atern (the latest version of DSDM - now on Atern v2) is a framework
based on best practice and lessons learnt since the early 1990's by
DSDM Consortium members.
• It provides a flexible yet controlled process that can be used to
deliver new systems, which combines the most effective use of
people's knowledge, tools and techniques such as prototyping to
achieve tight project delivery timescales.
• Time to market is of the essence in most organisations
Why choose DSDM Atern?
• There is increasing pressure on organisations to deliver working
systems to business in ever shorter timescales.
• The processes by which systems are developed need to be agile and
deliver what the business needs when it needs it.

DSDM implements the 80/20 rule--asserting that 80 percent of the solution is done in 20
percent of the time.
 What is Atern?
• Atern – the basic concepts
• User involvement ensures the right business solution
• Requirements evolve, but timescale is fixed
• Early delivery enables early pay-back
• Implement the 80/20 rule
• Nothing is built perfectly first time

Copyright DSDM Consortium 2009

What is Atern?

Copyright DSDM Consortium 2009

When Can I Use Atern?
• Not all projects will be full Atern but….

• You can use SOME of Atern ALL of the time

• You can use ALL of Atern SOME of the time

• The Project Approach Questionnaire (PAQ) helps identify projects

where Atern adds most value for least risk
Atern Components
 The Atern Philosophy The Atern Principles
• Projects must be aligned to clearly
defined strategic goals, and focus on
early delivery of business benefit
• To achieve this, key stakeholders
• Should understand business
objectives
• Should be empowered to the
appropriate level
• Collaborate to deliver the right
solution
• Accept that change is inevitable

Copyright DSDM Consortium 2009

Atern Process – The Lifecycle

Copyright DSDM Consortium 2009

 Atern Products
• Defined set of products for each lifecycle stage
• The system itself (evolving through iterative development)
• Planning and management products
• Technical products
• Quality and review products
• Support products
• Defined quality criteria for all products

Copyright DSDM Consortium 2009

 Atern People - Roles
• Executive Sponsor
• Commits funding
• Final say in decision making
• Visionary
• Greatest knowledge and view
• Supervising project direction
• Ambassador User
• User experience and knowledge

Copyright DSDM Consortium 2009

 Atern Techniques
DSDM defines 5 core techniques…

– Iterative Development
– Timeboxing
– MoSCoW Prioritisation
– Facilitated Workshops
– Modelling

Copyright DSDM Consortium 2009

Iterative Development
• Allows teams to evolve the solution from high level ideas to the delivered product
• Three perspectives…
• Functional perspective - demonstrates how a specific business objective has been achieved
by the evolutionary step
• Usability perspective – demonstrates how the user of the solution interacts with it to achieve
the business objective
• Non-functional perspective - demonstrates how general issues related to, for example
performance, capacity, maintainability have been accommodated
• Development cycles for Exploration and Engineering…

Copyright DSDM Consortium 2009

TimeBoxing
• DSDM adheres to strict deadline standards.
• The project is broken down into smaller items that each have a firm
budget and timeframe.
• To navigate this, requirements are prioritized.
• If time or money is running out, lowest priority requirements are
removed.
• A finished project then comes from only the most essential
requirement items.
Timeboxing • Development timebox
• Increment timebox
• Achieves defined objectives by a fixed deadline • Project timebox
• Leverages MoSCoW
• Maintains focus on on-time delivery – every time
• If it appears that deadlines could be missed, the deliverable should be de-scoped dropping
the lower priority items, i.e. Should Have and Could Have requirements can slip and timing
never does
• Manages dependencies within a project
• Enables regular assessment of real progress
• Prevents scope creep

Copyright DSDM Consortium 2009

Timebox example
1. Developing a Social Media Platform (6 months)➔ Project Timebox
2. Chat messenger, People can share their posts, Connecting with
different social media platforms, Enable access to link different
profiles and customize activities
1. Epic (1.5 months)➔ with 3 epics I may require 4.5 months (Development
Timebox)
1. User Stories (time for completing a particular iteration encompassing one or more user
stories are called iteration timebox)
MoSCoW Prioritisation
• This is the prioritization group used to rank items from the highest level of
importance to the lowest.
• The prioritizations groups are Must Have, Should Have, Could Have, and Won’t
Have.
• Must Have
• Requirements fundamental to solution
• Defines Minimum Usable Subset – basic working solution
• Should Have
• Requirements important to system
• Measured in terms of value or impact
• Could Have
• Can do without in the short term
• Won’t have this time
• Will wait till later
 MoSCoW Rules

Minimum Usable SubseT

(MUST) of requirements
which the project guarantees
to deliver

Requirements are important

but not vital

Requirements are wanted or

desirable but less important

3/6/2025
MoSCoW Prioritization
• Must-have. Projects often get too many must-haves. Identifying the real must-
haves is key to success. A simple way is to ask the question “if you do not get
this, should we still continue the project?”. If the answer is yes - it is NOT a must-
have.
• Aim is for about 60% Must Haves (i.e. 60% effort)
• Should-have. Not getting a should-have will hurt a lot, but there are
workarounds, even though they may be cumbersome and irritating.
• Could-have. Valuable requirements with a clear business case but we can do
without them.
• (Should and Could haves make up the remaining 40% effort)
• Won’t have this time. Legitimate requirements that we, for now, leave for later
increments / phases of this project.
MoSCoW Prioritisation
• Why prioritise?
• Not enough time to do everything
• Not enough resources to do everything
• Lack of money or lack of people (or both)
• MoSCoW means important things are done first
• Musts and Shoulds often deliver 80% of total business benefit
• MoSCoW priorities drive sequence of delivery
• Target is effort split 60% Must Have, 40% Shoulds and Coulds
• Predictable and sustainable delivery

Copyright DSDM Consortium 2009

MoSCoW Example on list of requiremets for a
project
Social media In every iteration refinements to previous
iteration has to be done
App S. User story task MoSCoW-I1 MoSCoW-I2 MosCoW-I3
No

1 Account Registration and Login Must

Iteration1(2 w)

2 Update Profile details Should

Iteration2(2 w)
3 Chat Messenger Could Must

Iteration3(2 w) 4 Create posts Must

5 Share Posts Should
6 Delete Posts Would Should
7 Link multiple social media Could Should
Platform
8 Setting template for my Account Would Could Should

9 Enabling payment wallet - Could Should

10 Making this account as - - Must(Refine

preliminary for other social media US7)
Facilitated Workshops
• Facilitated workshops are…
“A team based approach to communication”
• Workshops can, for example, be used for:
• *Defining requirements (MoSCoW list).
*Business analysis (process & work-flow models, etc).
*Solution design.
*User interface design.
*Problem solving.
*Project planning.
*Review & re-planning.

• “Using an interactive workshop environment, effective group dynamics and visual aids, facilitated
sessions are designed to extract high quality information in a compressed time frame, to meet a
predetermined set of deliverables.”
• Documentation→Documents are then excellent tools for writing down facts, figures and other
information for our collective memory.

Copyright DSDM Consortium 2009

Modelling
• Powerful
• Improves communication through shared
visualisation
• Models deployed according to project needs
• Atern advocates standard industry techniques…
• Selected to your organisation’s requirements
• Enough to satisfy the purpose – no more

Copyright DSDM Consortium 2009