Must Should Could Won't-retrospective Template (Free)

Wat is de Must Should Could Won't-prioriteringsmethode?

Must Should Could Won't, beter bekend als MoSCoW, verdeelt werk in vier groepen: wat je moet doen, wat je zou moeten doen, wat je kunt doen als er tijd over is en wat je deze keer niet doet. Als retrospective zorgt het ervoor dat je team hardop en met iedereen erbij afspraken maakt over de prioriteiten voor de volgende sprint of release. Dai Clegg ontwikkelde de methode in de jaren negentig bij Oracle. Daarna werd ze een vast onderdeel van agile projectmanagement en business analyse, vooral binnen DSDM. De categorieën zijn Must have (cruciaal), Should have (belangrijk), Could have (wenselijk) en Won't have (deze keer niet). De methode past goed bij agile werken, omdat het werk met de meeste waarde vooraan komt. Ook krijgt de product owner een gestructureerde manier om de backlog vanuit het perspectief van de klant te bekijken: als een klant het bij de lancering zou missen, is het waarschijnlijk een Must. De Won't-kolom doet meer dan je zou denken. Door op te schrijven wat je hebt afgesproken níet te doen, voorkom je dat het alsnog de sprint in sluipt. Bovendien weten stakeholders zo duidelijk wat er niet geleverd wordt.

Must Should Could Won't-format

Must Wat moeten we hoe dan ook opleveren?: Dit zijn niet-onderhandelbare eisen die cruciaal zijn voor succes. Moedig deelnemers bij de Must-items aan om te denken aan echte blokkades of essentiële onderdelen zonder welke het project zou mislukken. Daag het team uit om streng te zijn over wat als Must telt, zodat niet alles ineens topprioriteit krijgt.
Should Wat is belangrijk, maar niet cruciaal?: Dit zijn belangrijke functies of eisen die veel waarde toevoegen, maar niet cruciaal zijn voor de lancering. Help het team te kijken naar items die pijnlijk zijn om te laten liggen, maar het project niet laten stilvallen. Focus op items met veel waarde en minder urgentie.
Could Wat zou mooi zijn als er tijd over is?: Dit zijn wenselijke functies die leuk zijn om te hebben als de middelen het toelaten. Help het team verbeteringen te vinden die de oplossing beter maken, maar niet essentieel zijn. Deze items zijn vaak goede kandidaten voor latere iteraties of releases.
Won't Wat spreken we af deze keer niet te doen?: Dit zijn items waarvan het team bewust besluit ze voor deze iteratie of dit project niet op te pakken. Stimuleer een eerlijk gesprek over functies die misschien de moeite waard zijn, maar niet passen bij de huidige doelen of beperkingen. Door ze te benoemen blijft het team gefocust en zijn de verwachtingen helder.

Wanneer dient u deze retrospective te gebruiken?

Bij het plannen van een nieuw project of initiatief waarvoor je duidelijke prioriteiten nodig hebt
Tijdens backlog refinement, om featureverzoeken te sorteren en te prioriteren
Als de middelen krap zijn en je moeilijke keuzes over de scope moet maken
In overleg met stakeholders, om verwachtingen te managen over wat er wanneer wordt opgeleverd

Voorstellen voor ijsbrekers

Wat is de lastigste prioriteitskeuze die je ooit in een project hebt moeten maken?
Als je in je huidige project maar drie functies mocht opleveren, welke zouden dat zijn en waarom?

Wilt u een opwarmoefening waarbij uw team daadwerkelijk meedoet, en niet alleen hardop antwoorden geeft? Bekijk gratis ijsbrekers →

Ideeën en tips voor uw retrospectievevergadering

Houd Must-items op maximaal zo'n 60% van de totale inspanning, de richtlijn van DSDM, zodat het plan ruimte heeft voor verrassingen
Kijk opnieuw naar de categorieën als de bedrijfsbehoeften en beperkingen veranderen
Geef de bespreking van elk item een timebox, zodat één discussie niet de hele meeting opslokt
Schrijf op waarom elk item in een bepaalde categorie is beland, zodat de volgende discussie niet weer bij nul begint
Betrek de stakeholders die eigenaar zijn van de eisen, zodat de prioriteiten blijven staan
Controleer afhankelijkheden voordat je een item indeelt: een Could waar een Must van afhangt, is eigenlijk een Must

Veelgestelde vragen

Wat is de MoSCoW-methode?

MoSCoW is een prioriteringstechniek die werk verdeelt in vier categorieën: Must have, Should have, Could have en Won't have this time. Dai Clegg ontwikkelde de methode in de jaren negentig bij Oracle, en ze wordt veel gebruikt in agile en business analyse.

Wat betekenen Must, Should, Could en Won't?

Must is essentieel en niet onderhandelbaar. Should is belangrijk maar niet cruciaal, Could is wenselijk als er tijd is, en Won't valt volgens afspraak voorlopig buiten de scope.

Hoe voer je een MoSCoW-retrospective uit?

Zet de mogelijke werkitems op een rij, bespreek ze één voor één met het team en plaats elk item in de kolom Must, Should, Could of Won't. Stel elke Must ter discussie en wees het over elk item eens voordat je doorgaat naar het volgende.

Waarom heet het MoSCoW?

De hoofdletters staan voor Must, Should, Could en Won't. De twee o's staan er alleen in om het acroniem uitspreekbaar te maken.

Hoeveel items mogen een Must zijn?

DSDM, het agile framework dat MoSCoW bekend heeft gemaakt, raadt aan om Musts op maximaal zo'n 60% van de inspanning te houden. Als bijna alles een Must is, heeft het team niet echt geprioriteerd.

Wat is de Must Should Could Won't-prioriteringsmethode?

Must Should Could Won't-format

Must

Should

Could

Won't

Wanneer dient u deze retrospective te gebruiken?

Voorstellen voor ijsbrekers

Ideeën en tips voor uw retrospectievevergadering

Veelgestelde vragen

Gerelateerde sjablonen