Welke is flexibel: je budget, tijdlijn of scope?
In een perfecte wereld zijn bij softwareontwikkeling (1) alle vereisten helder, (2) is het precies duidelijk hoeveel werk deze gaan kosten en (3) doen zich nooit problemen voor. In de realiteit echter zijn softwareprojecten lastig in te schatten en doen zich soms onverwachte complicaties voor. Hoe ga je daarmee het beste om?
Traditioneel staat de scope van een project vaak vast. Bij complicaties wordt dan extra budget toegekend of wordt de oplevering uitgesteld. Dat leidt tot frustraties. Daarom is een moderne ‘best practice’ het vastzetten van budget en tijdlijn – en het flexibel maken van de scope. Een strakke prioritering is de sleutel om dat succesvol te doen. Een populaire manier daarvoor is de MoSCoW methode.
Waarom de MoSCoW methode?
Met de MoSCoW methode verdeel je de taken (de ‘user stories’) van je project in Must, Should, Could en Won’t haves. Dit is beter dan traditionele (High/Medium/Low) prioritering om deze twee redenen:
- Bij drie prioriteitsniveaus biedt de middelste optie (Medium) de mogelijkheid om besluiteloos te zijn over de prioriteit van dat onderdeel. Door vier niveaus te hanteren, dwing je jezelf te kiezen of een taak belangrijker of minder belangrijk is dan gemiddeld.
- Ook zet High/Medium/Low geen enkele verwachting over of een onderdeel wél of niet opgeleverd gaat worden, terwijl dat absoluut belangrijk is om te weten.
Must haves
Eerst maken je developers inschattingen per user story. Met inachtneming van die inschattingen en je budget, kun je deze user stories prioriteren. Must haves zijn de user stories zonder welke je software absoluut onbruikbaar zou zijn.
- Als voor een user story een workaround mogelijk is, is deze dus géén Must have.
- Het belangrijkste is dat je Must haves 100% zeker worden opgeleverd op tijd en binnen budget. Daarom moeten je Must haves maximaal 60% van je takenlijst opmaken, zodat je een flinke buffer hebt.
Should haves
Should haves zijn user stories die heel belangrijk zijn voor je software, maar niet compleet cruciaal. Bij voorkeur worden ook deze user stories op tijd en binnen budget opgeleverd. Echter is de software nog steeds bruikbaar zonder deze onderdelen.
Could haves
Alleen in een best-case-scenario worden ook Could haves opgeleverd.
- Je Could haves vormen een buffer om ervoor te zorgen dat ook je Should haves worden opgeleverd op tijd en binnen budget, daarom moet zeker 20% van je takenlijst uit Could haves bestaan.
- Zet je developers nooit onder druk om ook de Could haves zeker op te leveren. Dit leidt alleen maar tot nutteloze inschattingen die bewust veel te groot zijn gemaakt.
Of iets een Should of Could have is, verschilt per stakeholder. Daarom moet dit goed samen worden afgestemd. Bijvoorbeeld: op hoeveel mensen moet een user story impact hebben voordat deze een Should have wordt? Of: hoe duur moet het ontbreken van een user story zijn voordat deze een Should have wordt?
Won’t haves
Ten slotte zijn er je Won’t haves: user stories die zeker niet worden opgeleverd. Het is belangrijk deze ook op te schrijven. Dan is je lijst compleet en zijn er geen user stories waarover geen beslissing is gemaakt.
Tussentijdse opleveringen en sprints
Een softwareproject bestaat, naast de uiteindelijke deadline, meestal uit tussentijdse opleveringen en sprints. Per sprint en oplevering geldt een verschillende prioritering. Zo kan een user story in Week 1 een Won’t have zijn en in Week 6 een Must have. Zo houd je gaandeweg steeds overzicht over welke user stories wel al en nog niet gelukt zijn.
Met de MoSCoW-methode houd je focus op wat de belangrijkste onderdelen van je project zijn – en zorg je ervoor dat je project op tijd en binnen budget wordt opgeleverd. Zo neem je frustraties weg en ben je voorbereid als zich onderweg complicaties voordoen. Bij een complex project biedt dit de houvast die nodig is om tot een succesvolle oplevering te komen.
