Presentation on theme: "Master the art of MoSCoW Prioritisation"— Presentation transcript:
1Master the art of MoSCoW Prioritisation ...and protect the quality of what you deliver and deliver it on timeKeith RichardsChief ExecutiveKRC
2Presentation Structure IntroductionsThe basics about prioritisationIs everything a Must?Prioritisation at different levelsPractical tipsAdvanced prioritisationFurther information / Next stepsClose and questions.
3Introductions KRC is a pioneering training and consultancy company Specialising in Agile approachesFocusing on improving Agile capability at scale15 years experience in PRINCE2 and DSDM AternIAF Accredited / APMG Certified FacilitatorAuthor of ‘Agile Project Management’ (TSO)Voted ‘Most Valuable Agile Player’ UK Agile Awards.
4Why should we prioritise? FeaturesTimeCostQualityVariableFixedTraditional ApproachDSDM Approach
5Prioritisation in context Project EnvironmentProduct EnvironmentStrategic VisionProject GovernanceProject Management?ProjectsComplicatedUniqueNeeds to be managedBAURoutineEnhancementsSimple
6MoSCoW and the 80:20 rule X X Lose only ‘a little bit!’ MustYou won’t lose half of your project!Embraces change dynamicallyArchimedes law (‘Displacement’)ShouldNew!XCouldX… but the business/customer/user involved drives the decisions.Won’tPRL
7MoSCoWing 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 timeboxEnables flexing the requirementsEnables on time deliveryYou can use 1, 2, 3, ..,n. – if there are no dependencies…but how do you avoid everything being a Must?
8Is 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?
9Levels of prioritisation (granularity) Initially, only a few requirements to prioritisethey may all be MustsBefore delivery many more requirements will existShoulds and Coulds will now appearDuring delivery - detailed requirementsMany ways to solve the problemThe ‘UTH rule’ – units, tens and hundreds... or how about Boulders, Rocks and Gravel?
10MoSCoW in the real world requirements are rarely in isolationInheritance is normal – e.g. a Must within a Couldfunctional grouping occursdependencies – functional and non-functionalhence 1, 2, 3, ..., n – is too simplistic for most project situationssize and complexity is irrelevant.
11The 60:20:20 ‘rule of thumb’It is just a guide – not to be taken literallyLess than 60% is very importantIt relates to effortYou can relate requirements to the business caseUnderstand the Minimum Usable SubseTIt is guaranteedSimilar 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.
12Advanced prioritisation MoSCoWing non-functionals can be very powerfulUnderstand Bloat and YAGNIChange is going to happen – see it as ‘trading’Should/Coulds are OK but Must/Shoulds are not.
13Further Information / Next Steps Next webinar: April 12.30pmKRC help organisations with their transition to AgileKRC offers a variety of Agile training and support servicesMaturity assessment (project ‘health check’)Next AgilePM public course is on April 15th in LondonNext Certified ScrumMaster course is on April 13th in LondonFree downloads, including today’sJoin ‘The DSDM Group’ on LinkedInFollow us on
14Master the art of MoSCoW Prioritisation Thank you!