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 <type 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 probeert te 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 het productdoel en de productvisie.

Start bij het productdoel

Het idee bij agile requirements is dat je begint bij het productdoel en van daaruit de functionaliteit waarmee dat doel behaald kan worden, definieert. Dat doe je zo bij het definiëren van user stories én ook daarvoor al bij het definiëren van high level requirements.

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 <type 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 productdoel en de productvisie. Dat is niet nieuw, maar binnen agile speelt het productdoel een nog grotere rol dan het in het waterval tijdperk al deed.

Ga top down te werk

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 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). Hier leer je alles over in onze online training Juwelen van user stories.

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.

Zo krijg je het doel helder

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

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 doelen 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 …?’

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 & Priya Soekhai

Misschien vind je dit ook interessant

7 reacties

  • Thomas

    Wederom een interessante en leuke blog!
    Ik kom het inderdaad vaak tegen dat het bepalen van de “zodat” lastig is bij het opstellen van user stories. Het omdraaien van de user story waardoor de “zodat” vooraan komt te staan is een goede tip. Bedankt!

  • Rik Manhaeve

    In de laatste tip vermeld je:
    “De output is in dit verband de op te leveren software, de oplossing. De outcome komt daaruit voort.”

    Dit is meteen de aanduiding dat software geen business waarde kan opleveren, enkel de business kan dat.
    Software levert een “potentieel” op om waarde te realiseren.
    Software zal ook bijna nooit volstaan om dit potentieel te benutten, daar is veel meer voor nodig (bv change management, support organisatie, communicatie met de gebruikers op het juiste moment op de juiste manier).

    Software realisatie is dus geen project (wel projectmatig). Enkel het geheel kan je een echt project nomen (je kan het ook een programma noemen).

    Enkel outcomes die verbonden zijn met de strategie zijn waardevol, voor de rest is er geen tijd noch geld.

  • Hans

    Door de zin om te draaien wordt er niet ineens business waarde gegenereerd en wordt de waarde ook niet per definitie scherper. Jouw verbetering : “Om te bepalen of ik een alternatieve route ga nemen” is ook geen directe business waarde en zoals je zelf aangeeft is daarmee ook nietszeggend. Het is eerder klantwaarde en daarnaast is de businesswaarde niet het nemen van een alternatieve route, maar een snellere reis, groenere reis, goedkopere reis. En daarboven ligt nog veel meer waarden.

    • Nicole de Swart

      ‘Boven’ de klant-/businesswaarde ligt inderdaad nog veel meer waarde. Een user story moet immers bijdragen aan het doel waarvoor de software ontwikkeld wordt. Een te high level waarde in de user story-zin opnemen, helpt niet bij het implementeren van die story. Een te low level waarde wordt een open deur. Het is dus de kunst om het juist niveau te vinden. En dat is mede afhankelijk van de context.

  • Alexander

    Het gaat niet om hoe je het opschrijft maar om het gesprek dat je met de stakeholders hebt en de verdieping die je zoekt. In het voorbeeld van de file informatie is dat misschien net niet genoeg om de businesswaarde te genereren maar juist het inzicht in de duur van de vertraging. Dit kost tijd van de stakeholders en de analist en die claimen we vaak te weinig.

  • Sjoerd Huisman

    Bij ons stellen we intern vaak de vraag ‘welk probleem proberen we op te lossen?’. Het antwoord daarop drukt in feite de business-waarde uit.
    Het helpt tevens om de reeds aangedragen oplossing even los te laten, en vanuit het probleem / business waarde te redeneren wat de beste functionele oplossing is.

    Om diezelfde vraag aan de klant te stellen blijkt vaak ook wel weer heel lastig.

Geef een reactie