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? Features Time Cost Quality Variable Fixed Traditional Approach DSDM Approach

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

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

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?

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

Further Information / Next Steps Next webinar: April 26th @ 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 slides @ www.agilekrc.com Join ‘The DSDM Group’ on LinkedIn Follow us on Twitter @agilekrc

Master the art of MoSCoW Prioritisation Thank you! k.richards@agilekrc.com c.robinson@agilekrc.com www.agilekrc.com