MoSCoW-methode: vereisten prioriteren na een overleg
Pas MoSCoW toe op vereisten uit een gesprek: Must, Should, Could en Won’t voor de huidige periode. Met voorbeeld, vragen voor het team en een beslissjabloon.
Prioriteit hangt af van doel en periode
In het overleg noemde iedereen de eigen functie verplicht. Zo’n lijst helpt niet om de omvang te bepalen. Spreek eerst af wat de volgende release moet opleveren en wanneer die onbruikbaar zou zijn. In een andere fase kan de indeling heel anders uitvallen.
MoSCoW kent vier categorieën: Must Have, Should Have, Could Have en Won’t Have this time. De laatste sluit een vereiste bewust uit voor de besproken periode. Dat houdt geen toezegging voor later of definitieve afwijzing in.
Bespreek de gevolgen van weglaten
Beschrijf het doel van de release
Noteer de gebruiker, de taak en de gebruiksomstandigheden. Verduidelijk de beperkingen en de planningsperiode. Zolang het doel ‘het product verbeteren’ luidt, hanteren deelnemers verschillende criteria en wordt bijna alles verplicht.
Beoordeel kandidaten voor Must
Vraag per item of het resultaat zonder die vereiste bruikbaar blijft. Bekijk aanvaardbare tijdelijke oplossingen en afhankelijkheden. Een verplichte vereiste heeft een concrete reden nodig. ‘De leidinggevende vroeg erom’ noemt de bron, maar beschrijft niet wat er zonder gebeurt.
Onderscheid belangrijk van wenselijk
Een Should is belangrijk: zonder dit onderdeel is het resultaat merkbaar zwakker, maar nog bruikbaar. Een Could is een nuttige aanvulling die gemakkelijker weg te laten is. Leg het verschil uit aan de hand van de gebruikerstaak en de kosten van weglaten.
Spreek uitsluitingen en herbeoordeling af
Noteer voor een Won’t de reden en de voorwaarde om de bespreking opnieuw te openen. Controleer de afhankelijkheden en haalbaarheid van de gekozen omvang. Als verplicht werk meer capaciteit vraagt dan beschikbaar is, herzie dan de omvang of het plan. Een ander label lost het tekort niet op.
Eerste release van een inschrijfformulier voor een evenement
Dit is een fictief oefenvoorbeeld. Namen, omstandigheden en resultaten dienen alleen om de werkwijze uit te leggen.
We moeten een aanvraag kunnen ontvangen en de plek bevestigen. Het zou leuk zijn als iemand de kleur van de badge kan kiezen, maar het evenement kan ook zonder doorgaan. Voor een persoonlijk account hebben we voorlopig geen tijd.
In dit voorbeeld is het doel een deelnemer in te schrijven en een duidelijke bevestiging te geven. Een aanvraag indienen is Must omdat de hoofdtaak anders wegvalt. Een herinnering kan Should zijn als het team voorlopig een afgesproken alternatief heeft.
De badgekleur kan Could zijn en een persoonlijk account kan deze keer buiten scope blijven. Deze indeling geldt voor dit voorbeeld. Bij een ander evenement of publiek kunnen de gevolgen anders zijn.
| Vereiste | Categorie | Onderbouwing |
|---|---|---|
| Aanvraag indienen | Must | Anders vervalt de hoofdtaak |
| Herinnering ontvangen | Should | Belangrijk, met tijdelijk alternatief |
| Badgekleur kiezen | Could | Inschrijving blijft mogelijk |
| Persoonlijk account | Won’t deze keer | Buiten de afgesproken omvang |
Kaart voor de onderbouwing van prioriteit
Bewaar de reden naast de categorie. Zo kunt u het besluit herzien als de omstandigheden veranderen.
Release / periode / doel: Vereiste: Gebruikersscenario: Wat gebeurt er zonder de vereiste: Aanvaardbare tijdelijke oplossing, indien beschikbaar: Afhankelijkheden: MoSCoW-categorie: Onderbouwing: Wie het besluit heeft bevestigd: Voorwaarde voor herbeoordeling: Uitsluitingen voor deze periode:
Controleer of de lijst keuzes helpt maken
- Het doel en de periode staan bij de categorieën.
- Bij elke Must zijn de gevolgen van weglaten beschreven.
- Een tijdelijke oplossing is expliciet beoordeeld.
- Won’t deze keer wordt begrepen als een uitsluiting voor de huidige periode.
Een nadere blik
Kan een vereiste van categorie veranderen?
Ja, als het doel, de periode of een afhankelijkheid verandert, of als nieuwe gegevens beschikbaar komen. Noteer de reden en spreek de gevolgen voor de omvang af vóór u het item verplaatst.
Wat als alle vereisten Must zijn?
Vraag wat het resultaat zonder elk item onbruikbaar maakt, controleer alternatieven en beperk het doel. Herzie het plan als de verplichte omvang nog steeds te groot is.