Tijdens Scrum 2017 heb ik een workshop Product Backlog management mogen geven, waarvan ik de samenvatting snel in blogpost vorm zal delen. Ter voorbereiding op de workshop is mij gevraagd om voor het magazine wat die dag werd uitgedeeld een artikel te schrijven. Ik heb mij hiervoor laten inspireren door iets wat ik veel zie gebeuren bij klanten: De manier waarop het User Story template ‘misbruikt’ wordt. Enigszins aangepast naar aanleiding van feedback en vragen tijdens de workshop, is onderstaande wat er te lezen viel in het magazine:

Over eenden en honden…
Laatst zat ik een beetje na te denken over dieren. Je kent het wel: je gedachten dwalen een beetje af en dan bedenk je je allerlei gekke dingen… Ik bedacht me: een eend is een vogel, maar als ik aan vogels denk, denk ik niet zo snel aan eenden. Als ik aan vogels denk, dan denk ik aan vliegende dieren en je ziet eenden amper vliegen.

Een eend is een vogel, een parkietje ook. Maar als ik dan denk aan bijvoorbeeld een kat zou ik geen specifieke katsoorten kunnen noemen… Tenzij… een cheetah is ook weer een katachtige! En een hond dan? Een hond is een hond. Punt. Maar een Sint-Bernard is een hond en een Duitse Herder ook. En daar bleef ik even op hangen: je zou kunnen zeggen dat alle Duitse Herders honden zijn, maar niet alle honden zijn een Duitse Herder. Er zijn immers meerdere soorten.

“Alle Duitse Herders zijn honden, maar niet alle honden zijn een Duitse Herder.”

En als ex-militair bedacht ik me toen: “Elke soldaat is een militair, maar niet elke militair is een soldaat.” (aangezien soldaat een rang is – of een stand voor de puristen onder ons – en geen verzamelnaam). En zo is het ook met ‘User Stories’.

Over User Stories
Door de jaren heen is het voor heel veel Agile teams een soort standaard geworden om alle items op je Product- en Sprint Backlog maar een User Story te noemen. En de mensen die een training gevolgd hebben weten dan ook nog dat een User Story een bepaald template heeft (Als, wil ik , zodat). En dus moeten alle User Stories (of eigenlijk: alle items binnen je Product Backlog Management) voldoen aan dat template en noemen we alles gemakshalve maar een User Story.

Maar hoe zit dat dan met bijvoorbeeld de upgrade van een platform dan? Nou, simpel toch: “Als developer, wil ik dat de platform op de laatste versie is, zodat ik een stabiele omgeving heb.” En dat stukje technisch onderzoek wat we moeten doen om te weten of het systeem stabiel blijft bij het bouwen van die Epic? Nou, ook niet moeilijk: “Als systeembeheerder, wil ik weten of het systeem stabiel is, zodat ik nieuwe features kan gaan beheren.” En als dat stukje ‘zodat’ nou lastig te bepalen is? Dan doen we toch alleen “als gebruiker, wil ik…”?!

Op deze manier lijkt het soms wel een beetje alsof je een rondje door een vierkantje aan het drukken bent. En dat is dan ook vaak de feedback van de teams: “Waarom moet alles nou in dat User Story template passen? Dat voelt niet natuurlijk en kost ons teveel tijd om alles maar in dat format te schrijven.” En het grappige is, daar hebben ze ook helemaal gelijk in!

Over de theorie
Even terug naar de basis. Wat zegt Scrum ook alweer? De Product Backlog is de ‘single source of requirements for any changes to be made to the Product’. Op de Product Backlog staan dus alle items die het Development team moet oppakken om het Product te bouwen, beheren en onderhouden. Als je de Scrum Guide er op naslaat, zul je nergens de term User Story tegenkomen. Hier wordt alleen maar gesproken over Product Backlog Items (vaak afgekort tot PBI’s).

Dan nu even terug naar mijn voorbeeld met honden: alle Duitse Herders zijn honden, maar niet alle honden zijn Duitse Herders. En dat geldt ook voor User Stories: alle User Stories zijn Product Backlog Items, maar niet alle Product Backlog Items zijn User Stories!

Mijn tip is hierbij dan ook: probeer om niet (meer) als standaard reactie alles User Story te noemen, maar noem al de items op de Product BacklogProduct Backlog Items (PBI’s)’. Zeg niet meer: “Hoeveel User Stories kunnen we oppakken volgende Sprint?”, maar maak daarvan: “Hoeveel items kunnen we doen?”

Voor daadwerkelijke Product Features zou het raadzaam kunnen zijn om dat te doen in de vorm van een User Story, maar voor zaken als bijvoorbeeld een stukje technisch onderzoek van het Development team, zou je ook een zogenaamde ‘Spike’ kunnen gebruiken (of je noemt het gewoon ‘Technisch Onderzoek’).

Want wat zijn dan geschikte PBI’s zou je je af kunnen vragen? Nou… Alles! Use Cases, User Stories, Spikes, Bugs, Defects, Architectural Requests… You name it! Alles kan, als je maar duidelijk beschrijft wat het beoogde doel is van het item (wat wil je ermee bereiken). Hoe je dit beschrijft kan per item verschillen. Probeer dus niet de User Story op alles toe te passen, maar doe wat logisch is. En uiteraard, de bestaande Agile waardes in gedachten houdende: ‘Just in Time’, niet meer ‘BDUF’ (Big Design UpFront). Net zoals een User Story, moeten eigenlijk alle PBI’s een ‘invitation to a conversation’ zijn. Je werkt het pas volledig uit zodra het team het ook echt bijna op gaat pakken (en de noodzaak er is), om zo naast effectief te werken met Scrum, ook efficiënt te worden.

Over de workshop
Tijdens de workshop kreeg ik van een deelnemer hier wel een vraag over: “Maar de User Story helpt toch juist om op een makkelijke manier te beschrijven wat je zou willen?” En daar had ze ook absoluut gelijk in! Ik zeg ook niet dat je nooit meer een User Story template moet gebruiken, maar neem als take away mee dat niet alles een User Story is en dat je dus ook niet alles in dat format hoeft te beschrijven. Ik vind het altijd een overweging voor de Product Owner. Dat is de persoon die moet werken met de Product Backlog en dat is dus ook de persoon die hier keuzes in kan maken.

Over pro-tips gesproken
En dan als laatste tip nog: Als je wel met User Stories werkt, probeer dan te voorkomen dat je op de plek van de ‘rol’ elke keer ‘gebruiker’ zet. Dus, bijvoorbeeld:

Slechte User Story: ‘Als gebruiker wil ik een hotel kunnen boeken, zodat ik op vakantie kan.’

Betere User Story: ‘Als vader van een gezin wil ik een kamer met meerdere bedden kunnen boeken, zodat mijn kinderen bij mij op de kamer kunnen slapen.’

Op deze manier geef je als Product Owner (of stakeholder die het item aandraagt) meer context over de specifieke waarde die je wilt gaan leveren.

Veel succes met het toepassen en ik ben benieuwd naar jullie ervaringen met User Stories. Herken je bovenstaande? Motiveert dit om er eventueel anders mee om te gaan? Ik hoor graag van je!

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*