Agile/Scrum blog

Niet alle honden zijn een Duitse Herder

Willem Vermaak Door: Willem Vermaak,  28-03-2017
Onderwerp: Product backlog management  

Tijdens Scrum2017 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" word.

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 kat-soorten kunnen noemen... tenzij... een cheetah is ook weer een kat-achtige...

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 op je Product Backlog) gaan 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 moelijk:

"Als systeem beheerder, 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? Nou, ehh.. 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 geld ook voor User Storys:

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 Backlog "Product 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! 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 efficient 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 met 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!


Reactie(s) [0]

Geen reacties gevonden

Jouw reactie

Onderwerp:
Naam:
Email:
Website:
Reactie:

Wil je reageren op dit artikel? Zeker doen! Vul bovenstaande velden in en je reactie wordt direct geplaatst! Wij behouden echter wel het recht om reacties achteraf te verwijderen die volgens ons ongepast zijn.