Wat is de Moet Zou Kan Niet Prioriteringsmethode?
Onze acties moeten onze prioriteiten weerspiegelen, en Moet Zou Kan Niet is een uitstekende sprint retrospective template om teams te helpen deze prioriteiten te identificeren zodat ze waarde blijven leveren waar dat het meest nodig is. Met dat in gedachten is het een aanpak die goed aansluit bij agile processen en frameworks, gezien de focus op het eerst leveren van waardevolle zaken. Het is ook een geweldig Scrum sprint retrospective idee omdat het de product owner een mechanisme biedt om in de schoenen van hun klant te stappen en het product vanuit hun perspectief te bekijken. Ontwikkeld in de jaren '90 door Dai Clegg, kreeg de MSCW-methode bekendheid in agile projectmanagement en business analyse. Het biedt een gestructureerde manier om taken in vier verschillende categorieën te organiseren: Moet hebben (kritiek), Zou moeten hebben (belangrijk), Kan hebben (gewenst), en Niet hebben (geen prioriteit).
Moet Zou Kan Niet Format
Moet
Dingen die we absoluut moeten doen.
Dit zijn niet-onderhandelbare vereisten die kritiek zijn voor succes. Moedig deelnemers aan om na te denken over echte blokkades of essentiële elementen zonder welke het project zou mislukken. Daag het team uit om streng te zijn over wat als 'Moet' kwalificeert om prioriteitsinflatie te voorkomen.
Zou
Dingen die we zouden moeten doen.
Dit zijn belangrijke functies of vereisten die significante waarde toevoegen maar niet kritiek zijn voor lancering. Leid het team om items te overwegen die pijnlijk zouden zijn om weg te laten maar het project niet zouden stoppen. Focus op items met hoge waarde maar lagere urgentie.
Kan
Dingen die we zouden kunnen doen.
Dit zijn wenselijke functies die fijn zouden zijn om te hebben als er middelen beschikbaar zijn. Help het team verbeteringen te identificeren die de oplossing zouden verbeteren maar niet essentieel zijn. Deze items zijn vaak goede kandidaten voor toekomstige iteraties of releases.
Niet
Dingen die we niet gaan doen.
Dit zijn items waar expliciet tegen besloten is voor deze iteratie of project. Moedig eerlijke discussie aan over functies die, hoewel potentieel waardevol, niet aansluiten bij huidige doelen of beperkingen. Dit helpt focus te behouden en verwachtingen te managen.
Wanneer u deze retrospective gebruikt
- Bij het plannen van een nieuw project of initiatief en er duidelijke prioriteiten moeten worden vastgesteld
- Tijdens backlog refinement sessies om feature requests te organiseren en prioriteren
- Wanneer er resource beperkingen zijn en er moeilijke beslissingen over scope genomen moeten worden
- In stakeholder meetings om verwachtingen over deliverables en tijdslijnen op elkaar af te stemmen
Voorgestelde vragen voor ijsbrekers
- Wat is de moeilijkste prioriteitsbeslissing die je ooit hebt moeten maken in een project?
- Als je maar drie functies kon opleveren in je huidige project, welke zouden dat zijn en waarom?
Ideeën en tips voor uw retrospective vergadering
- Beperk 'Moet' items tot maximaal 60% van totale vereisten om realistische scope te behouden
- Herzie en pas categoriseringen periodiek aan als bedrijfsbehoeften en beperkingen veranderen
- Gebruik timeboxing tijdens discussies om efficiënte besluitvorming te waarborgen
- Documenteer de redenering achter categoriseringen om duidelijkheid en consistentie te behouden
- Betrek alle belangrijke stakeholders bij het prioriteringsproces om draagvlak te verzekeren
- Overweeg afhankelijkheden tussen items bij het toewijzen van categorieën
Nieuw bij retrospectives? Lees onze gids over het uitvoeren van een retrospective →