Het overzien van de scope in een startend project is erg lastig. Het vinden van de requirements gaat dan ook in het begin gelijktijdig met het bepalen van de scope. Via een agile projectaanpak wordt gewerkt aan onderdelen die waarde bieden voor de product owner en de organisatie. In deze blog behandel ik het proces van het vinden van requirements in de eerste gesprekken tot het vormen van een eerste backlog. De volgorde in deze eerste backlog wordt beïnvloed door economische factoren in plaats van de business owner met de vlotste babbel. Daarnaast wordt er ingegaan op het economisch resultaat en de verhouding met het aantal stories dat een development team kan leveren.

Functionele scope

De functionele scope zijn de diensten waar het product in voorziet die uiteindelijk worden gevat in requirements en een werkend product. Als een project van start gaat is dit echter zeer moeilijk te bevatten. Het vinden van use cases is een parallel proces met het bepalen van de scope. De binnen- buiten scope lijst die in een eerdere blog is besproken kan hierbij helpen. Een andere techniek die hier een opvolging aan geeft is het opstellen van economisch gedreven doelstellingen. Deze doelstellingen kunnen prima worden gebruikt als een eerste versie van een backlog om een project te starten. In deze blog beschrijf ik het proces om vanuit de eerste verkenningen en gesprekken te komen op een economische backlog.

Identificeren use cases

In een eerdere blog heb ik beschreven hoe het mogelijk is om te komen tot een aantal concrete actoren en rollen. Met dit proces als gegeven is het mogelijk om use cases te identificeren.

Voorbeeld actoren

Voorbeeld actoren

Een goede techniek om achter use cases te komen is om een aantal vragen te stellen aan de stakeholders. Iedere vraag kan worden gesteld vanuit het gezichtspunt van de actoren.

  • Wat proberen gebruikers binnen deze rol te bereiken?
  • Om te voldoen aan deze rol, wat zouden de gebruikers daarvoor moeten doen?
  • Wat zijn de hoofdtaken van gebruikers binnen deze rol?
  • Welke informatie moeten gebruikers onderzoeken, veranderen of creëren binnen deze rol?
  • Wat doen gebruikers binnen deze rol om geïnformeerd te worden?
  • Wat doen gebruikers binnen deze rol om het systeem te informeren?

Een andere methode is om de stakeholders te laten denken over scenario’s die het systeem moet (of juist niet) ondersteunen. De aandacht ligt hier wel op de gedrags-eisen vanuit actoren en niet de technische specificaties. Deze methoden en de eerder beschreven methode zijn te combineren. Het doel is om zoveel mogelijk informatie te verzamelen omtrent het gedrag van het systeem.
Een goede techniek is om het user story formaat te gebruiken bij het in kaart brengen van de verschillende behoeften van actoren.

Als [actor] wil ik [behoefte] zodat [reden].

Zoals eerder besproken biedt het use case diagram een overzicht van de totale scope van het te ontwerpen systeem. Het is hier dan ook een goede oefening om de stakeholders te confronteren met deze visuele uitwerking.

Use-case diagram voor het overzicht van de scope

Use-case diagram voor het overzicht van de scope

Economisch resultaat

Agile teams genereren een voorspelbare output die wordt gemeten in velocity. Deze velocity zegt echter niets over de waarde die aan het product wordt toegevoegd. Een backlog van een product heeft de eigenschap dat deze is gesorteerd op business value. De features die het eerst worden ontwikkeld bieden de meeste waarde voor de organisatie. De product owner is echter vrij in het bepalen van de volgorde.

Tijdens de start van het project is er nog vaak helemaal niets. Er is geen team, geen technische infrastructuur en geen product om feedback op te genereren en van te leren. De eerste stories in een backlog zullen met name in het teken staan van architectuur en het opdoen van kennis. In de eerste fase van een project wordt vooral ingegaan op het uitvoeren van een “proof of concept” (PoC). Deze PoC’s of ook wel spikes genoemd geven inzicht of de ontwerpen potentie hebben om waarde toe te voegen aan het product. De uitkomst van het team levert op dit moment dus nog niet veel business waarde. In de onderstaande grafiek is deze fase te herkennen aan de term “focus op kennis”.

Klantwaarde-ontwikkeling over tijd in een agile traject

Klantwaarde-ontwikkeling over tijd in een agile traject

Nadat de fundering voor het product is neergelegd en de infrastructuur geschikt is om user stories te ondersteunen wordt er veel waarde geleverd door het team. Nogmaals het team levert dezelfde output in velocity maar werkt nu aan de belangrijkste features van het product. In de grafiek is dit te zien aan de stijle curve. In deze fase is er een focus op het leveren van klantwaarde.

Na verloop van tijd levert het team geen hoge klantwaarde meer omdat de stories minder waarde toevoegen dan voorheen. Dit is een belangrijk moment voor de product owner en het management om te kijken of de investering nog uit het product te halen is (Return on Investment). Indien dit niet het geval is kan er worden gekozen voor een nieuwe feature in het product of een geheel nieuw product ernaast.

Prioriteit doelstellingen

Uit de inventarisatiefase komen use cases en user stories die nog geen volgorde van klantwaarde hebben. Sterker nog met de aanwezigheid van de business owners en andere stakeholders is dit een gevoelig onderwerp waar de product owner onder druk kan komen te staan. Vaak gelden andere dan economische factoren voor een user story om een hoge plek in de backlog te veroveren. De verschillende belangen van stakeholders zijn moeilijke factoren voor een product owner.

De belangrijkste beslisfactor is de kosten van vertraging (Cost of Delay). Deze kosten worden gemaakt indien er niet wordt geïnvesteerd in een oplossing. Het is goed  te visualiseren in een diagram. In het onderstaande voorbeeld wordt uitgegaan van twee user stories. User story A heeft een duur van 1 en een kosten van vertraging van 10. User story B heeft een duur van 10 en en een kosten van vertraging van 1. De grafiek laat zien dat de kosten veel hoger zijn indien user story B voor gaat op user story A.

Kosten van vertraging (Cost of Delay)

Kosten van vertraging (Cost of Delay)

Economische backlog

De kosten van vertragen zijn echter moeilijk hard te maken en te berekenen.  Er kan hierdoor gerekend worden met een aantal factoren.

  • Business waarde (relatieve waarde tussen stories voor de business-unit)
  • Tijd kritiek (is er rekening te houden met een deadline?)
  • Risicoreductie (wordt er een bepaald risico gereduceerd?)
  • Kansen (ontstaan er nieuwe kansen?)
  • Omvang (wat kost het in capaciteit en doorlooptijd?)

Deze factoren worden individueel ingeschat met dezelfde reeks uit het planningpoker waar 20 de hoogste waarde is (1, 2, 3, 5, 8, 13, 20). Met de volgende formule kan dan voor iedere user story of use case de gewogen waarde worden berekend. Dit wordt ook wel de “Weighted Shortest Job First” genoemd (WSJF). Deze term komt uit het Scaled Agile Framework.

Formule voor het berekenen van WSJF

Formule voor het berekenen van WSJF

In de onderstaande tabel wordt aan de hand van een voorbeeld duidelijk wat een mogelijke eerste opzet is van een backlog op basis van de WSJF factor. Hierin is er nog geen volgorde aangebracht op basis van de WSJF. Hoe hoger het getal, des te hoger de plek op de backlog zou moeten zijn. Nogmaals het is aan de product owner om een volgorde te kiezen.

Backlog met use cases (epics) waarin de WSJF is berekend

Backlog met use cases (epics) waarin de WSJF is berekend