Hoe bepaal je de businesswaarde van een user storyVeel analisten, product owners en ook stakeholders vinden het lastig om de businesswaarde die een bepaalde user story of PBI (product backlog item) levert, vast te stellen. We zien te vaak user stories met een nietszeggende of helemaal geen businesswaarde, zoals bijvoorbeeld:

Als automobilist wil ik file-informatie hebben, zodat ik weet waar de files staan.

Als je de business stakeholders naar hun eisen en wensen vraagt en die naar user stories ‘vertaalt’, is het niet vreemd dat je moeite hebt met het invullen van het laatste deel van de user story template (Als <gebruiker> wil ik <functionaliteit>, zodat <businesswaarde>).

Hoe graag stakeholders de functionaliteit ook willen hebben, op de vraag welke toegevoegde waarde of voordelen hen dat gaat brengen, volgt vaak niet meer dan een ‘open deur’ antwoord.

Dat komt omdat je begint met het definiëren van de gewenste functionaliteit en daar vervolgens businesswaarde aan toe probeert te kennen. Je denkt dan teveel vanuit (functionele) oplossingen en te weinig vanuit de voordelen of de toegevoegde waarden voor de business.

Start met de businesswaarde

Het idee bij agile requirements is dat je begint met de businesswaarde en van daaruit de functionaliteit waarmee die waarde behaald kan worden, definieert. Dat doe je zo bij het definiëren van user stories en ook daarvoor al bij het definiëren van releases en high level requirements.

TIP   Meer focus op de businesswaarde leggen kan door de user story zin te beginnen met de businesswaarde. Het template wordt dan:

Om(dat) <businesswaarde>, wil ik als <gebruiker> <functionaliteit>.

Zo voelt het natuurlijker om eerst de gewenste businesswaarde te onderkennen en daar de benodigde functionaliteit bij te zoeken. Voor het voorbeeld aan het begin van dit artikel krijg je dan:

Om te bepalen of ik een alternatieve route ga nemen, wil ik als automobilist file-informatie hebben.

User stories staan niet op zichzelf. Als het goed is vloeien ze op de volgende manier voort uit het bedrijfsdoel en de productvisie:

(Dat je eerst het bedrijfsdoel scherp moet hebben, is overigens niet nieuw, maar binnen agile is het nog belangrijker dan het in het waterval tijdperk al was.)

  1. Je begint altijd met het doel dat de business met de software wil behalen. Wat zijn de verbeteringen die het nieuwe systeem in het bedrijfsproces moet bewerkstelligen?
  2. Vervolgens breng je de high level requirements in kaart met de productvisie en een high level overzicht van de requirements (epics op de product backlog).
  3. Tijdens het sprinten deel je de epics (en hun businesswaarde) verder op totdat je uitkomt bij low level requirements (kleine user stories met businesswaarde).

De reden dat het bepalen van de businesswaarde van een user story zo lastig is, is meestal omdat de overall businesswaarde (doel) van de te ontwikkelen software niet helder is. 

Bedrijfsdoel achterhalen

Je moet dan eerst het bedrijfsdoel boven water zien te krijgen. Zeker wanneer je tijdens een lopend project vragen over het bedrijfsdoel gaat stellen, wordt je dat niet altijd in dank afgenomen. Stakeholders vinden het vaak bijzonder lastig om dat soort vragen te beantwoorden.

TIP   Doe alles wat je kunt om het ze gemakkelijker te maken je vragen te beantwoorden. Wat je bijvoorbeeld kunt doen is:

  • Voorbeelden van mogelijke bedrijfsdoelen erbij geven, zodat de stakeholder weet in welke richting hij kan denken. Bijvoorbeeld efficiënter werken, marktaandeel vergroten, voldoen aan wet- en regelgeving.
  • Vragen wat de voordelen van een reeds gekozen oplossing voor de business zijn en doorvragen waarom dat zo is?
  • Zelf een antwoord geven waarvan je weet dat de ander het er totaal niet mee eens is. Dan is de kans groot dat hij erg zijn best gaat doen om een beter antwoord te geven. Je vraagt bijvoorbeeld:

‘Is het zo dat jullie dit nieuwe systeem willen omdat …?’ of
‘Heb ik goed begrepen dat jullie de kosten van dit project denken terug te verdienen met …?

TIP   Soms is het niet handig om het woord ‘doel’ in de mond te nemen. Bijvoorbeeld als in de business case of het projectplan een doel staat dat feitelijk een oplossing is. Dan zou je handig gebruik kunnen maken van de Engelse termen ‘output’ en ‘outcome’. Die geven het onderscheid tussen oplossing en businesswaarde goed weer.

De output is in dit verband de op te leveren software, de oplossing. De outcome komt daaruit voort. Dus de voordelen die het de business (naar verwachting) oplevert. Dat kunnen bijvoorbeeld financiële voordelen of betere klantenservice zijn.

Wat is jouw ervaring met het bepalen van de businesswaarde? Vinden jouw stakeholders dat ook zo moeilijk? We vinden het leuk als je hieronder een reactie, opmerking of vraag achterlaat.


 

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Share This