Verbeter je user stories

Een van de moeilijkste dingen om te doen als Product Owner of als team, is het creëren van goede user stories. Het maken van sterk geformuleerde user stories, onderbouwd met de Definition of Done, acceptatiecriteria en misschien afhankelijkheden van andere user stories/mensen/missende kennis, laat weinig tot geen ruimte voor aannames.
#

Verbeter je user stories

Een van de moeilijkste dingen om te doen als Product Owner of als team, is het creëren van goede user stories. Het maken van sterk geformuleerde user stories, onderbouwd met de Definition of Done, acceptatiecriteria en misschien afhankelijkheden van andere user stories/mensen/missende kennis, laat weinig tot geen ruimte voor aannames.

Dit lijkt best logisch, toch? Maar zo logisch is dat niet in de praktijk. In tegendeel; het kan behoorlijk lastig zijn. Het kan erg lastig zijn voor de klant om precies te weten wat hij wil, laat staan dat jij dat dan kan gieten in een simpele hypothese. Hier zijn zeven tips om je hierbij te helpen:

#1: Focus op de gebruiker

Door te focussen op de gebruiker, laat je direct zien voor wie je het werk precies aan het maken bent. Noteer de exacte rol van de gebruiker. Door alleen ‘gebruiker’ op te schrijven, blijft het globaal. Als je een groot stuk software aan het bouwen bent, dat door meerdere afdelingen gebruikt gaat worden, duik je dieper op de exacte rol van de gebruiker. Stel dat we software voor een hotel aan het bouwen zijn. De ‘wie’ kan als volgt gedefinieerd worden: ‘Als baliemedewerker…’. Dit maakt het voor de Product Owner (PO) veel makkelijker om eventueel extra informatie op te halen, mocht dit nodig zijn, dan wanneer er alleen ‘gebruiker’ staat.

#2: Focus op het ‘wat’

Nu dat we weten wie de exacte gebruiker is, kunnen we gaan opschrijven wat we gaan maken. Dit is een specifieke feature, of actie, die de gebruiker kan uitoefenen. Laten we verder gaan op onze baliemedewerker story: ‘Als baliemedewerker, wil ik handmatig kamers kunnen boeken’. Nu weten we wat we gaan bouwen, maar we weten nog niet waarom we dat willen. Ja, omdat het ons werk is om dingen te bouwen. Maar we willen weten wat het precieze doel is van de functie, van de feature.

#3: Focus op de functie

De functie is het voordeel van wordt behaald door de feature die gebouwd wordt. Waarom wil de baliemedewerker deze functie precies? Is er een probleem dat opgelost moet worden, of is het iets dat hij niet per se nodig heeft, maar wel wil? Door het doel helder voor ogen te hebben, weten we precies hoe we dat doel kunnen behalen en kan de PO de prioriteit bepalen. Nu is de volledige user story compleet. ‘Als baliemedewerker, wil ik handmatig kamers kunnen boeken, zodat we niet volledig afhankelijk zijn van het internet’.

#4: Betrek de stakeholders/eindgebruikers

En ik bedoel echt betrekken. Zij zijn degene die zullen gaan werken met het product van het team, dus zij kunnen je voorzien van de beste inzichten en het gevoel dat zij willen met het product. Krijgen ze altijd precies wat ze willen? Zeer zeker niet. Maar jij kan hen wel helpen te bepalen wat er als eerste gedaan moet worden. Door duidelijk te maken dat hun mening écht van belang is, dat hun input van groot belang is voor het succes van het eindresultaat, zal ze ook laten voelen dat ze belangrijk zijn in het ontwikkelingsproces.

Als dit namelijk niet gedaan wordt, zal het team zelf moeten gaan bedenken wat zij vinden dat waarde heeft voor de klant. En dat leidt uiteraard naar discrepantie in de wederzijdse verwachtingen.

#5: Vraag vijf keer waarom

Vervolg het proces door de vraag ‘Waarom?’ vijf keer te stellen. Zo vaak? Ja, omdat dát de echte reden van het probleem bloot zal leggen. Deze techniek is een van de bekende technieken van de Toyota Motor Corporation (ontwikkeld door Sakichi Toyoda) om beter te worden in het afleveren van het beste product op de markt.

‘Als baliemedewerker, wil ik handmatig kamers kunnen boeken, zodat we niet volledig afhankelijk zijn van het internet’.

Waarom?: Zodat ik een kamer kan boeken voor de klant, ook als het internet eruit ligt.
Waarom?: Zodat de klant in ons hotel kan verblijven, ook al hebben ze niet vooraf geboekt.
Waarom?: Zodat we een brede spectrum services aan de klant kunnen bieden.
Waarom?: Omdat we het beste hotel in het land willen zijn.
Waarom?: Omdat dit ons helpt een grotere klantenkring te ontwikkelen en zodoende meer omzet kan genereren.

Dus het ultieme doel is het ondersteunen van het genereren van meer omzet. Het strategische voordeel dat de oplossing creëert is ondersteunend van de oorzaak van het probleem. Door achter de exacte oorzaak te komen, wordt het makkelijker om erachter te komen wat de klant echt wil en nodig heeft.

#6 Verfijn de user stories met alleen de relevante mensen

Een grote groep met stakeholders/eindgebruikers plus het team bij elkaar zal vaak resulteren in eindeloze discussie. Niet echt efficiënt dus. Jeff Bezos (oprichter van Amazon) houdt meetings makkelijk en efficiënt door het aantal aanwezigen te beperken tot ‘twee pizza’- grootte. Als twee grote pizza’s voldoende zijn om de hele kamer te voeden, kan de meeting nog efficiënt verlopen. Natuurlijk wil iedereen ergens wat over kunnen zeggen, maar laat de afdelingen zelf kiezen wie de beste vertegenwoordiger is. Datzelfde geldt voor het team; niet iedereen hoeft bij de meeting te zijn om user stories te verfijnen. Dat is niet alleen erg inefficiënt, maar ook nogal prijzig.

#7: Definieer de user stories een paar sprints van tevoren

Door zeker te stellen dat de user stories ver vooraf duidelijk zijn, maar niet te ver vooraf (maximaal 3 sprints. Alles daarna is te onzeker), zal je helpen om eventuele blokkades of afhankelijkheden te tackelen. Misschien heb je die ene Java-expert een paar dagen nodig die een erg drukke agenda heeft. Misschien heb je extra hardware nodig om wat tests te draaien. Zeker zijn dat deze dingen geregeld zijn, zal jouw leven, en dat van het team, een stuk makkelijker maken.

Dit zijn slechts een paar basistips in het vormen van user stories. Ik ben benieuwd welke andere technieken jij hebt gebruikt of misschien wel totaal out of the box hebt gedacht in het achterhalen van wat de klant wil en hoe je het team vertelt wat er gemaakt moet worden.

Voel je vrij om je ervaring te delen!

Auteur: Sander Dur - Scrum Master / Agile Coach bij AgilityMasters.com.

Share: