Zijn de User Stories bij jou niets anders dan taken op een backlog? En zijn deze óf zo goed als niet ingevuld, óf is de oplossing tot in detail uitgeschreven? Is het onduidelijk wie de eindgebruiker is, welk probleem er wordt opgelost, of wat de geleverde waarde is? Heb jij als Product Owner of Scrum Master contact met de gebruiker? Weet je überhaupt wie jouw gebruikers zijn?

Tijdens mijn opdracht bij de Rabobank kreeg ik een boek aanbevolen: ‘User Story Mapping’ by Jeff Patton. Een boek dat naast een uitwerking van de mapping-tool, ook inzichten biedt met betrekking tot het werken met User Stories. Dit boek gaat over hoe een gesprek met de gebruiker helpt om met behulp van User Stories daadwerkelijk waarde aan het product toe te voegen. Herken jij als Product Owner of Scrum Master bovenstaand scenario? En wil je weten hoe je dit zowel theoretisch als praktisch kan aanpakken? Lees dan verder.

Van klantbediening naar doktersconsult in theorie

De term User Story zegt niks over de inhoud, maar wel over het gebruik. Het zegt iets over de weergave van een gesprek met de gebruiker, waarin verteld wordt tegen welke problemen de gebruiker aanloopt en waarom dit als een probleem wordt ervaren. Dit geeft het team input om na te denken over een oplossing voor het probleem. Regelmatig zie ik dat een requirements document met de oplossing ‘over de schutting wordt gegooid’. Het ontwikkelteam bouwt dan, zonder inzicht in de klantbehoefte of het probleem, wat er in het document staat. De klant levert in dit geval de oplossing aan, zonder dat het ontwikkelteam wordt meegenomen in het probleem. Dit is hetzelfde als wanneer ik naar de dokter ga met een snee in mijn arm en zeg dat ik drie hechtingen wil, zonder dat het probleem is besproken.

Om van deze manier van werken af te komen, is User Story Mapping een handige tool. Het helpt je om samen met een gebruiker te kijken naar de ervaring, en in te zoomen op de problemen die zich hierbij voordoen. Het team krijgt de gelegenheid om vragen te stellen over wie, wat, wanneer, hoe en waarom. Om vervolgens gezamenlijk focus te krijgen op het probleem of de behoefte en als team met een oplossing te komen.

Van problemen naar waarde

User Story Mapping levert initieel een gesprek met de gebruiker op. En dat is al heel waardevol. Daarnaast levert het ook wederzijds begrip op. Waar is iedereen mee bezig? Waar lopen we tegenaan? Een gebruiker voelt zich gehoord, en het team voelt zich gezien en kan daadwerkelijk waarde toevoegen voor de gebruiker. Door in gesprek te gaan met de gebruiker neemt het verantwoordelijkheidsgevoel van het team toe. Het team wordt eigenaar van het product in plaats van uitvoerder van een losse taak op een takenlijst. Bovendien kan je door User Story Mapping achter meer plekken van verbeteringen komen dan waar het team en de gebruiker initieel over in gesprek gingen. Waar je in latere sessies dan weer op kan doorpakken.

User Story Mapping in het echte leven

Het eerste wat mij opviel bij het begeleiden van een User Story Mapping sessie, is dat het veel oefenen behoeft. Om te oefenen begon ik dan ook met een probleem wat we allemaal herkennen: een rommelig huis. Hoe kunnen we dit opknippen in stukjes waarde en waar zitten de problemen waar we tegenaan lopen?

Bijvoorbeeld: De gebruiker communiceert het volgende probleem: “Mijn huis is een rommel”. Vervolgens knippen we dit op in stukken waarde, zoals: “de keuken opruimen” waarbij de subtaken weer kunnen worden onderverdeeld in: “schoonmaakmiddelen pakken” en “koelkast leegruimen”. Al deze subtaken op zich leveren iets op, maar zijn ook onderdeel van de oplossing voor het probleem. Het is duidelijk welke stappen we zetten en hoe deze stappen bijdragen aan het hogere doel

In het gesprek met een gebruiker doe je eigenlijk exact hetzelfde. Alleen zijn de problemen dan oplosbaar door het ontwikkelteam. Hierbij moet er ook gedacht worden aan sizing. Hoe groot of klein moet iets zijn om duidelijk, afgerond, overdraagbaar en waardevol te zijn zonder het gevoel te geven dat er meer wordt gedocumenteerd dan gedaan.

Zelf aan de slag

Ik hoop dat dit blogartikel nieuwe inzichten biedt waar jij wat mee kan! Nu kan ik mij voorstellen dat je na het lezen van dit blogartikel ook af wilt van die takenlijst als backlog en User Stories wil gebruiken als vastlegging van het gesprek over waarde met de eindgebruiker. Bij Bartosz helpen we jou en jouw afdeling graag verder in het proces van waarde leveren. Neem gerust contact met mij op om daar meer te weten over te komen.