Presentation on theme: "Master the art of MoSCoW Prioritisation Keith Richards Chief Executive KRC...and protect the quality of what you deliver and deliver it on time."— Presentation transcript:
Master the art of MoSCoW Prioritisation Keith Richards Chief Executive KRC...and protect the quality of what you deliver and deliver it on time
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?
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 Wont X X New! Lose only a little bit! You wont 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 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.
Further Information / Next Steps Next webinar: April pm 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 15 th in London Next Certified ScrumMaster course is on April 13 th in London Free downloads, including todays Join The DSDM Group on LinkedIn Follow us on
Master the art of MoSCoW Prioritisation Thank you!