• Product Backlog is een geordende lijst van alle zaken waarvan bekend is dat die nodig zijn voor het product. Het is de enige bron van vereisten voor eventuele aanpassingen aan het product.
• In de Product Backlog worden alle kenmerken, functies, vereisten, verbeteringen en oplossingen vermeld die onderdeel uitmaken van de wijzigingen die in toekomstige releases worden doorgevoerd. Product Backlog-items bevatten de kenmerken van een beschrijving, volgorde, raming en waarde. Er zijn ook vaak testbeschrijvingen waarin wordt aangeduid wanneer een item gereed of 'Done' is.

Je moet dus starten met een backlog, indien nodig prioriteiten stellen en eerst de belangrijkste items bouwen. SCRUM – en Agile ontwikkeling in het algemeen – is zowel incrementeel als iteratief (kijk hier of hier voor een duidelijke uitleg van die termen). We kunnen dit verduidelijken aan de hand van een voorbeeld. Als een klant een auto bestelt – en we bij het implementeren SCRUM gebruiken – kunnen we het chassis als basis herhalen en de auto incrementeel of stapsgewijs als volgt bouwen:

Voor Product Owners (de rol die projectmanagers op zich nemen) resteren er echter wel nog enkele vragen:

• Waar komt die backlog vandaan?
• Hoe weet ik zeker dat het voldoet aan de behoeften van de eindgebruiker?
• Hoe weet ik zeker dat het ontwikkelingsteam ook daadwerkelijk mijn interpretatie van de vereisten levert?
• Hoe weet ik zeker dat ik me aanpas aan wijzigingen én dat ik mijn architect een duidelijke (minder aan veranderingen onderhevige) set met parameters geef om mee te werken?

We zullen in deze blog geleidelijk antwoord geven op deze vragen.

Stel de onderliggende behoeften van de klant centraal

Laten we beginnen met de tweede vraag in onze lijst: hoe weet ik zeker dat het voldoet aan de behoeften van de eindgebruiker? Henrik Kniberg merkt terecht het volgende op:

We beginnen met hetzelfde scenario: de klant heeft een auto besteld. Maar dit keer bouwen we niet simpelweg een auto. We richten ons in plaats daarvan op de onderliggende behoeften die de klant vervuld wil zien. Het blijkt dat de onderliggende behoefte bestaat uit "Ik wil sneller van A naar B" en een auto is daar een van de mogelijke oplossingen voor.

In vergelijking met ons vorige voorbeeld waarin de klant een auto bestelde, zou dit er nu als volgt uitzien:

Dit betekent dus feitelijk dat je eerst moet bepalen wat het echte probleem is en dat je waar nodig aanpassingen moet doorvoeren. Het oplossen van het probleem verloopt van nature iteratief: je moet aanpassingen blijven doorvoeren totdat wordt bevestigd dat je een daadwerkelijke behoefte hebt opgelost. Je omschrijft wat volgens jou de meest optimale oplossing zou kunnen zijn voor de eindgebruiker. Is de eindgebruiker niet tevreden? Dan moet je dieper op de materie ingaan en alternatieven bedenken. Je zult uiteindelijk raak schieten en bevestigd krijgen dat je het probleem hebt begrepen. Die bevestiging kan gebaseerd zijn op echte gebruikersgegevens, kwalitatieve inzichten of een combinatie van beide.

SCRUM licht niet toe hoe we het idee van Henrik moeten implementeren. Ik begrijp dat er een voorkeur is voor het ontwikkelen van software en een sprint die eindigt met een verbetering of increment. Dit betekent dat werkende software tijdens de iteratie als een artefact wordt gebruikt om het probleem te bepalen. Het nadeel is echter dat het team alle reeds geïmplementeerde verbeteringen moet reviseren en moet aanpassen aan de nieuwe inzichten. Ik heb gekeken welke soorten afval softwareontwikkeling oplevert en dit is wat er mogelijk zou kunnen gebeuren:

• schatting niet mogelijk vanwege ontoereikende analyse of ontoereikend verzamelen van gegevens (Partially Done Work = deels afgehandelde werkzaamheden).
• technische complexiteit niet correct geanalyseerd (Partially Done Work), omdat dit onlogisch is om te doen tijdens een iteratie.
• verkeerde technologie of oplossing gekozen (Defects = defecten), omdat niet-functionele vereisten constant veranderen.
• ontwerp herzien omdat er vereisten zijn overgeslagen (Defects).

Dit zijn problemen die moeten worden opgepakt en ze kunnen worden opgelost door een goede Product Discovery-stap te implementeren.

Laten we nogmaals kijken naar de mogelijke vragen waarmee een Product Owner blijft zitten en welke we al hebben beantwoord:

• Waar komt deze backlog vandaan?
• Hoe weet ik zeker dat het voldoet aan de behoeften van de eindgebruiker?
  • We beginnen met een idee en we blijven net zolang zoeken en herhalen tot onze oplossing voldoet aan die behoeften. We blijven dit doen totdat we bevestigd worden.
• Hoe weet ik zeker dat het ontwikkelingsteam ook daadwerkelijk mijn interpretatie van de vereisten levert?
• Hoe weet ik zeker dat ik me aanpas aan wijzigingen én dat ik mijn architect een duidelijke (minder aan veranderingen onderhevige) set met parameters geef om mee te werken?
  • Het probleem wordt hierdoor groter: het ontwikkelingsteam moet (in ieder geval deels) zaken verbeteren naar aanleiding van de wijzigingen.

Bepaal wat je gebruiker nodig heeft

Om het afval uit het voorbeeld van Henrik te voorkomen, moeten we het iteratieve deel (bepalen wat de gebruiker nodig heeft) en het bouwen van de software (het creëren van een oplossing voor het probleem) opsplitsen. Om te bepalen wat de gebruiker nodig heeft, is een zogenaamde discovery-stap vereist.

Marty Cagan, de “most influential person in the product space”, is het hiermee eens:

In het voorbeeld van Henrik werkt het team samen om gelijktijdig te bepalen wat het juiste product is om te bouwen en om het daadwerkelijk te bouwen. Hun belangrijkste tool? De engineers. We zien een progressief ontwikkeld product waarbij de grootste nadruk ligt op het ontwikkelen van iets dat bij elke iteratie kan worden getest op echte gebruikers.

Henrik onderstreept dat er wordt gebouwd om te leren, maar ze doen dit met de enige tool die ze denken te hebben: de door engineers geschreven code. Als we goed lezen dan zien we dat Henrik benadrukt dat engineers niet daadwerkelijk producten hoeven te bouwen – ze kunnen ook prototypes bouwen, maar dit is iets waar de meeste teams die ik tegenkom niets mee kunnen. Ze begrijpen namelijk niet dat er heel veel verschillende soorten prototypes zijn die niet door engineers worden gecreëerd.

Dat klopt: het schrijven van software kan weliswaar een goede manier zijn om te achterhalen wat de gebruiker wil, maar het is doorgaans ook de duurste methode.

Door een 'discovery'-stap toe te voegen, kunnen we ons richten op de doelstellingen van een product: heeft het waarde, is het bruikbaar, haalbaar en rendabel? Deze stap is grotendeels iteratief. Het resultaat is een helder inzicht in het probleem en een mogelijke oplossing; een oplossing die hoogstwaarschijnlijk voldoet aan de behoeften van de gebruiker. Je kunt het enigineeringsteam dankzij de discovery-stap uitleggen wat het echte probleem is. Je kunt bovendien dieper ingaan op het probleem en uitleggen welke eigenschappen de eindoplossing moet bevatten, zoals een fitnessfunctie die de oplossing in een context plaatst. De ontwikkelingsteams bepalen vervolgens hoe ze die oplossing gaan bouwen. Dit is de leveringsstap en die verloopt over het algemeen incrementeel.

Product Discovery-traject versus Delivery-traject

Het team moet bij de Product Discovery- en leveringsstappen rekening houden met twee trajecten: één voor Product Discovery en één voor levering.

Laten we de vragen van de Product Owner voor de derde keer bekijken om te ontdekken welke er zijn beantwoord:

• Waar komt deze backlog vandaan?
• Hoe weet ik zeker dat het voldoet aan de behoeften van de eindgebruiker?
  
  • We beginnen met een idee en we blijven net zolang zoeken en herhalen tot onze oplossing voldoet aan die behoeften.
  • We moeten meer tijd doorbrengen met onze eindgebruikers om echt inzicht te krijgen in hun probleem.
  • We moeten dit zo snel mogelijk doen om te voorkomen dat engineeringswerkzaamheden stagneren.
• Hoe weet ik zeker dat het ontwikkelingsteam ook daadwerkelijk mijn interpretatie van de vereisten levert?
  • Ik kan bij de beschrijving van het probleem meer details en een bredere context verschaffen.
• Hoe weet ik zeker dat ik me aanpas aan wijzigingen én dat ik mijn architect een duidelijke (minder aan veranderingen onderhevige) set met parameters geef om mee te werken?
  
  • Engineers weten voordat ze een geschikte architectuur voor de taak bedenken al dat het een auto gaat worden en kunnen dus besluiten om die architectuur te implementeren met een andere leveringsstrategie dan een die is ontworpen om snel te leren.
  • Leveringswerkzaamheden verlopen veel soepeler dan anders doordat risico's tijdens de discovery-stap al worden aangepakt en omdat duidelijk is welke leveringswerkzaamheden er zijn.

Dual Track: Product Discovery en levering verlopen simultaan

Discovery-werkzaamheden richten zich op snel leren en validatie. Maar hoe koppel je dat aan leveringswerkzaamheden? Wellicht dat je bij aanvang van een project begint met discovery en dat je daarna - na verloop van tijd - het engineeringteam laat starten.

Dat ziet er dan zo uit

Dat lijkt heel erg op een  watervalmethode! Maar dat hoeft niet het geval te zijn. Volgens Jeff Patton, een doorgewinterde productmanager en schrijver van het boek User Story Mapping, gebeurt alles op hetzelfde moment (Dual Track). Zo krijgen we geen waterval maar een cyclus. Een leercyclus ziet er bij discovery bijvoorbeeld zo uit:

We beginnen met het beschrijven

• van wat volgens ons het probleem is dat we proberen op te lossen en voor wie we dat doen,
• de oplossing voor het probleem,
• en hoe we het succesvolle verloop gaan meten.

Een Product Discovery-cyclus ziet er als volgt uit:

De cycluslengtes bij discovery zijn onregelmatig. Het is 'lean' omdat we proberen om de discovery-cyclus zo kort mogelijk te houden. Ideeën veranderen tijdens de discovery-stap en worden vaak geschrapt, zodat de overgang naar meer doelgerichte cycli eenvoudiger wordt.

Takeaway

Om mogelijke risico's te kunnen elimineren, is het van belang om je bewust te zijn van de discovery- en leveringsstappen. De discovery-stap richt zich op de doelstellingen van een product: waarde, bruikbaarheid, haalbaarheid en rentabiliteit, en verloopt grotendeels iteratief. De leveringsstap richt zich op het bouwen van een product en verloopt doorgaans incrementeel. Dit zijn afzonderlijke stappen, maar de trajecten verlopen gelijktijdig. Dit noemen we Dual Track.

In het artikel van Jeff Patton over Dual Track worden ook een aantal belangrijke punten aangekaart.

• Deze twee trajecten bestaan uit twee verschillende werkzaamheden die door hetzelfde team worden uitgevoerd.
  • Tijdens de discovery-stap moet regelmatig met het team worden overlegd over haalbaarheid, correcte implementatie en technische beperkingen die van invloed zijn op ontwerpkeuzen.
  • De inzichten die discovery oplevert worden door het leveringsteam gebruikt tijdens de ontwikkeling.
• De discovery-stap richt zich eerst op de meest risicovolle aannames, zoals gebruikersproblemen waarvan we niet verwachten dat die een echte gebruikersbehoefte oplossen (of de behoefte is onbekend).
• De leveringsstap richt zich op oplossingen waarvan we in hoge mate verwachten dat die een gebruikersprobleem oplossen.
  • Dit vertrouwen kan het resultaat zijn van gevalideerde leerervaringen tijdens de discovery-stap.
  • Of we beginnen bij aanvang van een cyclus bijvoorbeeld met backlog-items die volgens ons geen discovery-stap behoeven, zoals technische werkzaamheden of functies waarvan we al in hoge mate verwachten dat deze een gebruikersprobleem oplossen.

Deze twee trajecten verlopen parallel:

• Discovery / iteratief: gericht op de meest risicovolle aannames (problemen waar we het minste van weten) en het definiëren daarvan op de meest eenvoudige manier.
• Levering/ incrementeel: gericht op een vastomlijnde oplossing (we hebben er vertrouwen in dat de eindgebruiker er behoefte aan heeft) en die met de hoogste waarde worden eerst aangepakt.

De trajecten stoppen niet zodra je een probleem hebt geconstateerd dat moet worden opgelost. Het volgende probleem ligt alweer op de loer. In ons voorbeeld van de klant die een auto bestelt ("Ik wil sneller van A naar B"), is de kans aanwezig dat de gebruiker ook een onderkomen zoekt, uiteenlopend van een eenvoudig hutje tot een kasteel.

Een laatste opmerking: deze blog begon met SCRUM als kader, maar de methodologie doet eigenlijk niet ter zake. Het kan Kanban, Crystal XP en zelfs Waterfall zijn als het team het tempo in beide trajecten maar kan bijbenen. Een Agile methodologie is echter wel een betere keuze, omdat discovery zich immers grotendeels richt op sneller leren.

Overige vragen

Laten we de vragen van de Product Owner nog één keer bekijken om te ontdekken welke er nu allemaal zijn beantwoord:

• Waar komt deze backlog vandaan?
  • De backlog is gebaseerd op aannames die tijdens de discovery-stap worden gevalideerd.
  • Maar er is nog een andere vraag: hoe bepalen we op welke aannames we onze aandacht richten? Waar komt het overzicht met kansen vandaan?
• Hoe weet ik zeker dat het voldoet aan de behoeften van de eindgebruiker?
  • We beginnen met een idee en we blijven net zolang zoeken en herhalen tot onze oplossing voldoet aan die behoeften.
  • Ik moet meer tijd doorbrengen met mijn eindgebruikers om echt inzicht te krijgen in hun probleem.
  • Ik moet dit zo snel mogelijk doen om te voorkomen dat engineeringswerkzaamheden stagneren.
  • Doe dit parallel en met het hele team.
• Hoe weet ik zeker dat het ontwikkelingsteam ook daadwerkelijk mijn interpretatie van de vereisten levert?
  • Ik kan bij de beschrijving van het probleem meer details en een bredere context verschaffen.
  • Betrek (in ieder geval een deel) van je engineeringsteam bij de discovery-stap. Zo komen ze in aanraking met de daadwerkelijke eindgebruiker en krijgen ze meer inzicht in de echte wereld van de gebruiker.
• Hoe weet ik zeker dat ik me aanpas aan wijzigingen én dat ik mijn architect een duidelijke (minder aan veranderingen onderhevige) set met parameters geef om mee te werken?
  • Engineers weten al dat het een auto wordt voordat ze een geschikte architectuur voor de taak kunnen bedenken. Ze kunnen zelfs besluiten om die architectuur te implementeren met een andere leveringsstrategie dan een die is ontworpen om snel te leren.
  • De risico's worden tijdens de discovery-stap aangepakt en het is duidelijk welke leveringswerkzaamheden er zijn. Leveringswerkzaamheden verlopen veel soepeler dan anders.