Hoe je de businesswaarde van een user story bepaalt

Veel analisten, product owners en business stakeholders vinden het lastig om de businesswaarde van een user story of PBI (product backlog item) te bepalen. We zien te vaak user stories met een nietszeggende of helemaal geen businesswaarde, zoals bijvoorbeeld in deze user story:

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 businesswaarde 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 wilt kennen. Je denkt dan teveel vanuit (functionele) oplossingen en te weinig vanuit de voordelen of de toegevoegde waarden voor de business.

De businesswaarde van een user story bepalen

Het wordt een ander verhaal als je top down gaat werken en dus begint met de businesswaarde die de user story moet leveren. Die businesswaarde leid je af uit de productvisie met daarin het bedrijfsdoel.

Start bij 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 én 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 voort uit het bedrijfsdoel en de productvisie. Dat is niet nieuw, maar binnen agile speelt het bedrijfsdoel een nog grotere rol dan het in het waterval tijdperk al deed.

Start bij het doel van het systeem

Met andere woorden werk top down. Dat doe je in agile op de volgende manier: 

  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 van de te ontwikkelen software niet helder is. Dus dat de eerste stap niet goed gaat.

Maak eerst het doel helder

Het valt niet altijd mee om het bedrijfsdoel boven water te krijgen. Zeker wanneer je tijdens een lopend project vragen over het bedrijfsdoel gaat stellen, wordt je dat soms in dank afgenomen. Stakeholders vinden het vaak bijzonder lastig om dat soort vragen te beantwoorden.

TIP – Doe alles wat je kunt om het de stakeholders 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 vloeit 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 je stakeholders het ook zo moeilijk? We vinden het leuk als je hieronder een reactie, opmerking of vraag achterlaat.


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.

Gratis e-book ‘Vliegende start als agile analist’

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

Copy link