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

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 Chief Executive of KRC KRC is a pioneering company at the forefront of agile thinking Specialising in all things agile (Scrum, DSDM, AgilePM, everything!) Consultancy, training, coaching and mentoring Focusing on improving Agile capability at any scale 20 years of experience Detailed knowledge of combining PRINCE2 with agile IAF Accredited / APMG Certified Facilitator Author of ‘Agile Project Management’ (TSO) Voted ‘Most Valuable Agile Player’ UK Agile Awards.

Why should we prioritise?

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

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

MoSCoWing Must have, Should have, Could have and Won’t have this time It has to relate to time (or a deadline) Enables flexing the requirements Enables on time delivery Helps protect the quality of what you deliver …but how do you avoid everything being a Must?

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?

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 Try Boulders, Rocks and Gravel?

MoSCoW in the real world Requirements are rarely in isolation Functional grouping occurs Dependencies – functional and non-functional Inheritance is normal – e.g. a Must within a Could Hence 1, 2, 3,..., n. is too simplistic for most project situations …and this is why Coulds get done before Musts!

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

Prioritisation levels The priority for the project may be different to that of an increment or timebox #55 Must #55 Could#55 Must Project Level Increment Level

Advanced prioritisation Size and complexity is irrelevant 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.

Further Information / Next Steps Today’s slides can be found at You will be sent a link by DSDM to a recording of this webinar downloadswww.agilekrc.com The Streetwise MoSCoW guide The Webinar Graphic by Stuart Young DSDM Membership Join ‘The DSDM Group’ on LinkedIn Follow us on

Master the art of MoSCoW Prioritisation Thank you!