Master the art of

MoSCoW Prioritisation
...and protect the quality of what you
deliver and deliver it on time
Keith Richards
Chief Executive
KRC
Presentation Structure
Introductions

The basics about prioritisation

Is everything a Must?

Prioritisation at different levels

Practical tips

Advanced prioritisation

Further information / Next steps

Close and questions.

Introductions
KRC is a pioneering training and consultancy company

Specialising in Agile approaches

Focusing on improving Agile capability at scale

15 years experience in PRINCE2 and DSDM Atern

IAF Accredited / APMG Certified Facilitator

Author of Agile Project Management (TSO)

Voted Most Valuable Agile Player UK Agile Awards.

Why should we prioritise?

Traditional Approach DSDM Approach

Featur Fixed Time Cost

es

Quality

Quality

Time Cost Variable

 Prioritisation in context

Project Environment Product Environment

Strategic Vision

Project Governance

Project Management

Projects BAU
Complicated Routine
Unique Enhancements
Needs to be managed Simple
MoSCoW and the 80:20 rule

Lose only a little bit!

Must
You wont lose half of your project!
Embraces change dynamically
Archimedes law (Displacement)
Should

X New!
Could
X but the business/customer/user
Wont
involved drives the decisions.

PRL
MoSCoWing
Must have, Should have, Could have and Wont have this time
The priority for the project may be different to that of an
increment or timebox
Enables flexing the requirements
Enables on time delivery
You can use 1, 2, 3, ..,n. if there are no dependencies

but how do you avoid everything being a Must?

Is it really a MUST?

Without it, it wont work so dont give me anything!

is there another way?

Can it be done manually?
How is it being done now?
Levels of prioritisation (granularity)
Initially, only a few requirements to prioritise
they may all be Musts
Before delivery many more requirements will exist
Shoulds and Coulds will now appear
During delivery - detailed requirements
Many ways to solve the problem

The UTH rule units, tens and hundreds

... or how about Boulders, Rocks and Gravel?
MoSCoW in the real world
requirements are rarely in isolation
Inheritance is normal e.g. a Must within a Could
functional grouping occurs
dependencies functional and non-functional
hence 1, 2, 3, ..., n is too simplistic for most project
situations
size and complexity is irrelevant.
The 60:20:20 rule of thumb
It is just a guide not to be taken literally
Less than 60% is very important
It relates to effort
You can relate requirements to the business case
Understand the Minimum Usable SubseT
It is guaranteed
Similar to minimum viable product (MVP)
Similar to minimum marketable feature set (MMFS)
Look to deliver the Musts, Shoulds...
... and as many of the Coulds as you can.
Advanced prioritisation
MoSCoWing non-functionals can be very powerful
Understand Bloat and YAGNI
Change is going to happen see it as trading
Should/Coulds are OK but Must/Shoulds are not.
 Master the art of
MoSCoW Prioritisation

Thank you!
k.richards@agilekrc.com
c.robinson@agilekrc.com
www.agilekrc.com