In deze gastblog legt Christiaan Kleczewski uit hoe je met een Minimal Viable Product en Scrum feedback kunt krijgen om het juiste product te ontwikkelen.
Wat is een Minimal Viable Product?
Een Minimal Viable Product (MVP) is de eerste versie van een product dat zo snel mogelijk wordt gereleaset naar de eindgebruiker. Het doel is om hiermee in een vroeg stadium van de softwareontwikkeling feedback te krijgen. Deze feedback gebruik je om de belangrijkste componenten te onderscheiden voor de volgende incrementele release.
Waarom een Minimal Viable Product?
Een van de belangrijke redenen om software development te doen volgens het Scrum Framework is dat er snel en veelvuldig feedback te krijgen is van de gebruikers.
Tijdens elke sprint wordt een Sprint Review meeting gehouden waarin het opgeleverde increment wordt gedemonstreerd aan de stakeholders.
Om snel te kunnen weten of het Scrum team op de goede weg is, is naast de feedback tijdens de Sprint Review, gebruikers-feedback op de MVP van de software van enorme waarde.
Doordat klanten snel een eerste versie van de software kunnen gebruiken, krijg je als team snel door of de gemaakte keuzes waardevol zijn.
Gebruikers geven namelijk doordat ze daadwerkelijk met de software kunnen werken snel aan welke aspecten wel en welke aspecten voor hen geen waarde hebben.
In het ergste geval geven gebruikers aan dat er geen waarde zit in het product. Het team kan dan bepalen een andere weg in te slaan.
Als pas na het volledig ontwikkelen van de software duidelijk dat deze geen meerwaarde heeft voor je klanten, zou kostbare ontwikkeltijd en veel geld voor niets zijn geïnvesteerd.
Als de MVP wel in de smaak valt, bepaal je door middel van de feedback welke volgende functionaliteiten de meeste waarde toe voegen voor de klant.
De Product Owner bepaalt aan de hand van de feedback welke functionaliteiten nodig zijn voor de volgende versie. Deze functionaliteiten worden dan weer als items met hoge prioriteit toegevoegd aan de Product Backlog en vormen samen 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 Minimal Viable Product?
De MVP vertegenwoordigt dus het minimale product dat waarde heeft voor de gebruikers. Maar hoe bepaal je welke functionaliteiten deze minimale waarde vertegenwoordigen?
Een manier om te bepalen welke minimale functionaliteit 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 een bed in een hotel. Een hotelkamer zonder bed, maakt de gasten erg ontevreden.
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 grootte van de hotelkamer. Hoe meer ruimte 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 hotel. 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 MVP, op te leveren, moeten in ieder geval die basisfactoren die van belang zijn voor de (subset aan) gebruikers aan wie de MVP wordt aangeboden.
Aangezien softwareontwikkeling erom gaat om iets nieuws te bieden aan de klanten, is het naast de basisfactoren belangrijk om minstens een prestatie of een WOW-factor op te nemen.
Het is de verantwoordelijkheid van de Product Owner om bij de klanten en andere stakeholders op te halen welke zaken belangrijk zijn voor het behalen van de MVP. De Product Owner gaat het gesprek aan aan de hand van de visie rondom de softwareontwikkeling.
Uit deze gesprekken volgen de verschillende gewenste functionaliteiten en de ordening daarvan.
Dit is een gastblog geschreven door Christiaan Kleczewski van Agile Scrum Group. Agile Scrum Group traint, coacht, en adviseert individuen en teams die slimmer willen samenwerken. Daarbij put de organisatie veelal uit het Agile gedachtegoed.
Waarde leveren aan gebruikers
Dank je wel Christiaan Kleczewski voor je gastblog over Minimal Viable Product en Scrum. Een MVP helpt je om snel goede feedback te krijgen en geeft inzicht in de behoeften, waardoor je meer waarde kunt leveren aan gebruikers.
Samenwerken met korte communicatielijnen is een sterkte van Scrum, die helpt om de kwaliteit te verhogen door datgene te leveren waar klanten wat aan hebben. Een MVP versterkt de leercyclus waardoor je nog beter in staat bent om met Scrum kwaliteitsproducten en diensten te leveren.
Een goede samenwerking van teams en product owners gedurende de gehele iteratie zorgt voor producten met de juiste functionaliteit en kwaliteit. Product Owner en Team: Samen Beter. DE product owner kan de verbinding leggen tussen het team en (potentiële) gebruikers, door iedereen te betrekken wordt er een beter product met meer waarde geleverd.
Met Lean Startup kun je leveren waar de klant wat aan heeft. Build-Measure-Learn is de cyclus die je doorloopt: Je maakt een product(versie), levert die aan klanten, en gebruikt de feedback om te leren wat de klant wil, en het product te verbeteren (persevere) of om een andere product te maken (pivot).
