1. Master the art of MoSCoW Prioritisation
...and protect the quality of what you deliver and deliver it on time
Keith Richards
Chief Executive
KRC

2. 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.

3. 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.

4. Why should we prioritise?
Features
Time
Cost
Quality
Variable
Fixed
Traditional Approach
DSDM Approach

5. Prioritisation in context
Project Environment
Product Environment
Strategic Vision
Project Governance
Project Management ?
Projects
Complicated
Unique
Needs to be managed
BAU
Routine
Enhancements
Simple

6. MoSCoW and the 80:20 rule X X Lose only ‘a little bit!’
Must
You won’t lose half of your project!
Embraces change dynamically
Archimedes law (‘Displacement’)
Should
New! X
Could X
… but the business/customer/user involved drives the decisions.
Won’t
PRL

7. MoSCoWing Must have, Should have, Could have and Won’t 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?

8. Is it really a MUST?
Without it, it won’t work – so don’t give me anything!
…is there another way?
Can it be done manually?
How is it being done now?

9. 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?

10. 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.

11. 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.

12. 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.

13. Further Information / Next Steps
Next webinar: April 12.30pm
KRC help organisations with their transition to Agile
KRC offers a variety of Agile training and support services
Maturity assessment (project ‘health check’)
Next AgilePM public course is on April 15th in London
Next Certified ScrumMaster course is on April 13th in London
Free downloads, including today’s
Join ‘The DSDM Group’ on LinkedIn
Follow us on

14. Master the art of MoSCoW Prioritisation
Thank you!