Verschil Product Backlog Items & User Stories

Een vraag die veel beginnende scrummers dwarszit is: “Hoe verhouden User Stories zich tot PBIs? ” Dat in de diverse certificeringen hiernaar wordt gevraagd, of ernaar wordt gehint, ligt uiteraard vaak deels ten grondslag aan deze vaak online gegooglede vraag. We hopen hiermee een tipje van de sluier op te lichten.

Product Backlog vs. User Stories

Allereerst dan maar wat is een PBI? Een PBI is een Product Backlog Item—en zo’n item bevindt zich op de Product Backlog. Op de Product Backlog vinden we in principe alle zaken die leiden tot het Product Goal—en dat is het commitment wat ligt op de Product Backlog. Deze is in beheer bij de Product Owner; die is ervoor verantwoordelijk dat de Product Backlog er is, dat deze op orde is en die is ook de enige die het mandaat heeft in scrum om de Product Backlog te prioriteren.

Het Product Goal is goed omschreven en alles wat op de Product Backlog staat moet daar naar toe leiden. Nu is het zo dat in scrum we meestal werken in een complexe situatie—en de scope is soms nog niet helemaal duidelijk of kan wellicht wijzigen. Daarom werken we op de Product Backlog met verschillende lagen van prioriteit, om zoveel mogelijk met focus te kunnen werken.

Helemaal bovenaan de Product Backlog staan de items die het meeste prioriteit hebben, en sprintklaar zijn. Dat betekent dat ze klein genoeg zijn om afgehandeld te kunnen worden met andere items in een sprint. Helemaal onderin vinden we de Epics—de hele grote items die nog niet klein genoeg zijn om mee te nemen in een sprint en nog wel wat discussie en refinement verdienen.

De Product Owner moet er minstens voor zorgen dat er een initiële Product Backlog is, die geprioriteerd is, zodat we een eerste sprintplanning kunnen laten plaatsvinden. Helemaal bovenaan staan de zaken die de meeste prioriteit hebben. De Product Owner, als Value Maximizer of Value Optimizer, zorgt er hiermee voor dat de eerste sprint meteen veel waarde toevoegt.

Mocht het zo zijn dat we niet genoeg weten, of zelfs de verkeerde dingen doen in de eerste sprint, dan leren we daar als team samen met de stakeholders heel veel van in de eerste review. Hierin zie je het empirisme terug wat in scrum zo belangrijk is; we leren steeds meer tijdens het proces. “We like to fail early”, horen we veel scrummers dan ook zeggen. Beter dat het nu misgaat, dan dat we heel lang in de verkeerde richting denken en lang geen waarde toevoegen voor de Stakeholders.

Als je aan twee kanten van een rivier begint met een brug bouwen, weet je graag zeker dat je in het midden bij elkaar komt—en zo zit het ook met de samenwerking met de Stakeholders in scrum. Het is belangrijk om hun wensen goed in het team te laten doorklinken—zodat de Developers goed weten waaraan ze kunnen gaan werken. Die wensen moeten dan wel zo transparant mogelijk op de Product Backlog staan. Bovenaan zo precies en klein, zo sprintklaar, dat ze in de volgende sprint gewoon opgepakt kunnen worden door de Developers, onderaan meer als grotere wensen en kenmerken, de zogenaamde Epics.

De rol van User Stories in Scrum

Een Product Owner is niet verantwoordelijk voor hoe de zaken door de Developers uitgevoerd gaan worden. Hij is alleen verantwoordelijk voor wat de stakeholders precies willen, en waarom ze dat willen—hierin zit de waarde voor de stakeholders. Om goed door te kunnen geven aan de Developers waar de wensen van de klant liggen, zonder zelf direct met oplossingen te komen, is een klein verhaal, een User Story, dan de meest gebruikte vorm. Hierin wordt uitgedrukt ie de klant/stakeholder is, wat die wil en waarom die dat wil. Een voorbeeld van een User Story (een epic in dit geval) zou kunnen zijn:

WIE Jeroen, de CEO van de fabriek die onder vuur ligt

WAT wil een mediatraining voor hemzelf

WAAROM zodat hij geen negatief gevoel over de fabriek achterlaat bij de pers

En waarom is dit een Epic? Omdat er veel meer informatie nodig is dan dit om een echt goede training te kunnen maken. Daarvoor moeten we als team nog veel meer vragen stellen over de wie wat en waarom—en hiermee refinen wij de backlog. De Product Owner blijft ervoor verantwoordelijk—maar het refinen doet deze vaak in samenwerking met de developers, dat delegeert hij als het ware meestal.

Analyse van PBIs en User Stories

Samenvattend: Op de Product Backlog staan Product Backlog Items, PBIs, die geschreven kunnen worden als User Stories. Maar let wel, dat is niet verplicht! Natuurlijk kun je bij zeer technische items volstaan met requirements. Een kanttekening is deze: Het maakt het leven van een team wel veel gemakkelijker in de review, die draait om feedback op het Increment, als de waarde voor deze stakeholder ook wordt besproken. “Weet je nog wel, beste klant, je wilde een oplossing voor het volgende probleem”. Even de waarde, het waarom, terugbrengen in het gesprek zorgt vaak voor een sfeer waarin ook niet-technische mensen nog vragen durven te stellen. En dat dient uiteindelijk het doel van scrum: zoveel mogelijk leren om een zo waardevol mogelijk product te kunnen leveren aan de Stakeholders.