slim
samen
werken

Minimum Viable Product en Scrum

Wat is een Minimum Viable Product?

Een Minimum Viable Product (MVP) is de eerste versie van een product of dienst die zo vroeg mogelijk wordt uitgerold naar de klant. Het doel is om daarmee zo snel mogelijk feedback te krijgen. Deze feedback is belangrijk om hiermee de belangrijkste vervolgstappen te kunnen nemen.

Waarom een Minimum Viable Product?

Een van de belangrijke voordelen van Scrum is dat er snel en veelvuldig feedback te krijgen is van de stakeholders.
Na elke sprint is er immers een Sprint Review meeting waarin het opgeleverde (deel)product (Increment) wordt gedemonstreerd.

Om snel te kunnen weten of het Scrum team op de goede weg is (is naast de feedback tijdens de Sprint Review) klanten feedback op de eerste versie (de MVP) van het product of dienst goud waard.

Doordat klanten gebruik kunnen maken van een eerste versie van het product, krijg je als team snel door of de gemaakte keuzes in de smaak vallen.
Gebruikers geven immers snel aan welke aspecten wel en welke aspecten geen waarde hebben.
In het ergste geval geven gebruikers aan dat er geen waarde zit in het opgeleverde. Het team kan dan bepalen een andere weg in te slaan.
Als dit pas duidelijk is na het volledig ontwikkelen van het product of de dienst zou hiermee kostbare tijd en veel geld voor niets zijn geïnvesteerd.

Als de MVP wel in de smaak valt, bepaal je door middel van de feedback welke functionaliteiten de meeste waarde toevoegen voor de klant.
Deze functionaliteiten worden dan weer als items met hoge prioriteit toegevoegd aan de Product Backlog.

De Product Owner bepaalt aan de hand van de feedback welke functionaliteiten nodig zijn voor de volgende versie. Ook nu gaat het weer om zo mogelijk een oplevering naar de klant te kunnen doen. De feedback op deze versie leidt dan weer tot nieuwe inzichten.

Hoe bepaal je het Minimum Viable Product?

De MVP vertegenwoordigt dus het minimale product of dienst die waarde heeft voor de klanten. Maar hoe bepaal je welke functionaliteiten deze minimale waarde vertegenwoordigen?

Een manier om te bepalen welke functionaliteit minimaal nodig is, is het zogenaamde Kano-model te gebruiken. Dit model is in de jaren 80 van de vorige eeuw ontwikkeld door Noriako Kano.

In dit model staan twee indicatoren: de x-as gaat over de aanwezigheid van een bepaalde factor en de y-as gaat over de tevredenheid die die aanwezigheid voor de klant met zich meebrengt.

Basisfactor
Dit zijn die factoren die minimaal nodig zijn. Als deze factoren niet aanwezig zijn, is de klant per definitie ontevreden.
Een voorbeeld van een basisfactor is hygiëne in een restaurant. Als er ongedierte rondloopt in een restaurant, zullen de klanten zeker een blokje om lopen op zoek naar een alternatief.

Prestatiefactor
Deze factoren hebben grote invloed op de tevredenheid van de klanten. Indien de prestatiefactoren niet aanwezig zijn, is de klant ontevreden. Meer aanwezigheid leidt tot grotere tevredenheid bij de klant.
Een voorbeeld van een prestatiefactor is de kwaliteit van het voedsel. Hoe beter hoe tevredener de klanten zijn.

WOW-factoren
Als deze factoren niet aanwezig zijn, zal de klant ze niet missen. Als ze er wel zijn, hebben ze direct positieve invloed op de tevredenheid. Dit zijn dus zaken waarvan de klant vaak niet wist dat hij ze wilde.
Een voorbeeld van een WOW-factor is valet parking bij het restaurant. Als dit er niet is, dan gaan klanten ergens anders parkeren. Als het wel mogelijk is, is dit een mooie extra functionaliteit.

Om een waardevolle eerste versie van een product of dienst, de MVP, op te leveren, moeten in ieder geval alle basisfactoren aanwezig zijn. In ieder geval die basisfactoren die van belang zijn voor de (subset aan) klanten die in aanraking gaan komen met de Minimum Viable Product.
Aangezien de meeste MVPs iets nieuws willen bieden aan de klanten, is het naast de basisfactoren belangrijk om minstens een prestatie of een WOW-factor op te nemen.

Het inventariseren en rubriceren van de functionaliteiten die nodig zijn voor een bepaald product of dienst is de verantwoordelijkheid van de Product Owner.
Deze gaat aan de hand van de visie rondom de ontwikkeling in gesprek met de stakeholders.
Uit deze gesprekken volgen de verschillende gewenste functionaliteiten en de ordening daarvan.
In onze blog over de productvisie vind je een model waarmee de Product Owner dit op een gestructureerde manier kan doen.

Ook interessant:

Volg ons op LinkedIn (we delen onze blogs met je)

Over de auteur: Christiaan Kleczewski

Christiaan is Agile Coach en trainer. Zijn expertise ligt op het implementeren en begeleiden van Agile in organisaties en Scrum en andere raamwerken in teams. Dit doet hij op een pragmatische manier met aandacht voor de specifieke omstandigheden in de organisatie en de teams. Immers, organisaties en teams bestaan uit mensen en mensen zijn allemaal anders. Christiaan deelt zijn kennis en ervaring in blogs die regelmatig te lezen zijn op deze website.

LINKEDIN
Follow by Email
Schrijf je in om om de week de nieuwste Agile inzichten te ontvangen