4 Product backlog prioritiseringtechnieken

1. MoSCoW Methode

MoSCoW is een prioriteringstechniek die is ontwikkeld door Dai Clegg van Oracle. De techniek is afkomstig uit de softwareontwikkeling en is bekend geworden door het frequent gebruik als onderdeel van de Agile ontwikkelmethode Dynamics Systems Development Method (DSDM). Hoewel afkomstig uit de softwareontwikkeling, wordt de techniek inmiddels toegepast in allerlei sectoren, waaronder de industrie, consultancy en andere zakelijke dienstverlening.

MoSCoW staat voor:

• Must have. Een must have is een harde eis waaraan niet te tornen valt. Hier moeten we gewoonweg aan voldoen. Als het beoogde resultaat niet wordt behaald, voldoet het projectresultaat niet aan de eisen en is de oplevering of het project mislukt.
• Should have. Een should have is ook een eis, maar geen keiharde. Hieraan moeten we eigenlijk ook voldoen, maar er is wel enige speling: misschien mag het resultaat enigszins afwijken, is er een alternatieve oplossing mogelijk, of kunnen we de eis bij een volgende oplevering meenemen.
• Could have. Een could have is geen eis, maar een wens. Onze inspanning heeft meerwaarde en het is zeker nuttig de wens in te vullen, maar dit is niet noodzakelijk. Could haves zijn zaken waar je tijd aan kunt besteden als aan de must en should haves is voldaan en er nog wat tijd en middelen over zijn.
• Won’t have. Een won’t have is een eis of wens, waarvan is afgesproken dat deze – in ieder geval in de huidige sprint/oplevering – niet binnen de scope valt. Het is dus niet zo, dat het leuk zou zijn als deze eis of wens wordt ingevuld. Integendeel: er mogen aan een won’t have geen tijd en resources besteed worden, want dit heeft namelijk geen toegevoegde waarde of gaat ten koste van belangrijkere requirements.

Labelen van eisen en wensen
Door eisen en wensen van een ‘label’ te voorzien, ontstaat een snelle eerste prioritering, die vervolgens nader kan worden gedetailleerd. Je kunt dit vergelijken met medische triage, waarbij bij binnenkomst van een patiënt wordt bekeken of deze een overlevingskans heeft, meteen behandeld moet worden of wel even kan wachten.
Must en should haves vereisen urgente aandacht, waarbij de must haves de belangrijkste categorie vormt. Pas nadat deze twee categorieën voldoende aandacht hebben gekregen en ‘in control’ zijn, mag aandacht worden besteed aan could haves. En won’t haves… jammer maar helaas; hieraan moet je geen kostbare tijd en resources besteden.

De MoSCoW-methode helpt bij het sorteren en organiseren van uw productitems op een geclassificeerde manier die succesvolle resultaten oplevert. Deze methode is gebaseerd op de deskundige mening van elk team. Het is gemakkelijk en snel te voltooien en definieert de prioriteiten van functies die worden uitgevoerd.

2. Kano Model

In de jaren ’80 ontwikkelde Noriako Kano het Kano-model. Je kan er de verwachtingen, prioriteiten en de expliciete behoeften van de klant mee in kaart brengen. Het model bevat twee indicatoren: er wordt gekeken in welke mate een klantbehoefte is vervuld en wat voor mate van tevredenheid dit met zich meebrengt. Er wordt daarnaast onderscheid gemaakt tussen drie factoren: basisfactoren, prestatiefactoren en WOW-factoren:

• Basisfactoren

Dit zijn de factoren die op zijn minst aanwezig moeten zijn, de basisbehoeften van het product of de dienst. Een telefoon moet kunnen bellen en een hotelkamer heeft een bed nodig. Als deze factoren niet aanwezig zijn, zal dit zorgen dat de klant ontevreden is. Andersom gaat dit niet per se op: als je meer bedden neerzet zal de klant niet direct meer tevreden zijn.

• Prestatiefactoren

Bij de prestatiefactoren, de performers, geldt dat hoe meer ze aanwezig zijn, hoe meer tevreden de klant is. In een hotelkamer kan de grootte een prestatiefactor zijn, hoe groter de hotelkamer is, hoe meer tevreden de gast is. Bij een telefoon kan je denken aan een goede camerafunctie, hoe beter deze is, hoe meer tevreden de gebruiker is.

• WOW-factoren

De WOW-factoren zijn de delighters. De dingen die een klant niet verwacht, en niet mist als ze niet aanwezig zijn. Maar als ze wel aanwezig zijn, zorgen ze voor een sterke toename in tevredenheid. Een welkomstdrankje of een verse schaal fruit op de hotelkamer wordt niet verwacht, maar kan wel zeer aangenaam zijn. Of denk aan een gratis hoesje bij je nieuwe telefoon, of een nieuwe functie die een handeling gemakkelijker maakt.

Het toepassen van het Kano-model

Als organisatie moet je als eerst zorgen dat je basisfactoren op orde zijn. Zodat de klant in de basis altijd tevreden is. Daarna ga je werken aan je prestatiefactoren, zorgen dat de klant net wat meer tevreden is en ook terugkomt. Als laatste voeg je af en toe een WOW-factor toe, zorg dat de klanten af en toe echt worden verrast.

Als de WOW-factoren steeds weer op dezelfde manier voorkomen, worden het vanzelf basisfactoren. Denk bijvoorbeeld aan Wi-Fi in hotelkamers. Waar dit een tijdje geleden nog als WOW-factor werd gezien, is het inmiddels voor de meeste mensen al een standaard verwachting, een basisfactor.

Een uitgebreide uitleg over Kano kunt u hier vinden: The Complete Guide to Kano.

3. Affinity Analysis

Met de Affinity Analysis-techniek categoriseren ontwikkelingsteams gebruikersverhalen in verschillende manden zoals hoog, laag, gemiddeld, enz.

Verder kiezen ze backlog items om te verzorgen, plannen of bouwen. Teams gebruiken deze techniek om groepen prioriteit te geven op basis van hun belangrijkheidsniveau.

Het idee achter deze Affinity-techniek is simpel. Deelnemers brainstormen samen over verschillende ideeën en mogelijkheden.

Vervolgens brengt het team hun nieuwe ideeën en plannen in kaart in thematische clusters. Daarna stemmen teams en rangschikken ze elke groep na het vaststellen van affiniteitsanalyse.

Aan het einde van de activiteit heeft het team een ​​geprioriteerde lijst met nieuwe ideeën.

4. Stack Ranking

Een veelgebruikte prioriteringstechniek, gestapelde rangschikking, wordt in meerdere industrieën gebruikt. Op het meest basale niveau is gestapelde rangschikking het nemen van uw lijst met items (ideeën, verhalen, heldendichten, enz.) die prioriteit moeten krijgen en deze rangschikken van de meest belangrijke (bovenaan de stapel) tot de minst belangrijke (onderaan). de stapel). Dat is alles – gemakkelijk, toch?

Het antwoord is ja en nee. Hoewel de prioriteringstechniek in de praktijk eenvoudig is, berust deze op kwalitatieve gegevens en meningen, die mogelijk niet in overeenstemming zijn met de gebruikerswaarde.

Deze twee dingen onderscheiden Stack Ranking van andere methoden:

Mogelijkheid van slechts één nummer één – Dit biedt de mogelijkheid om een ​​vertrouwde (en eerlijk gezegd stressvolle) productvalkuil te vermijden waarin alles een hoge voorkeur krijgt.

Vaak nauwkeuriger, minder verwarrend. Je geeft prioriteit aan elk item ten opzichte van alle andere items, wat het proces vereenvoudigt en transparanter maakt. Dit is meestal een specifiekere en gemakkelijkere manier om prioriteiten te stellen dan om absolute waarden te geven (zoals “zeer hoge prioriteit”).