Follow Us on Twitter

Succesvol Product Backlog beheer voor Scrum Product Owners

Gepubliceerd in

November 2013 - In software ontwikkeling staat de release datum vaak vast. De scope van het product is dan een van de belangrijkste variabelen. Scope kan gebruikt worden om te sturen en is daarmee bepalend voor de mate van succes. De scope wordt in Agile projecten vastgelegd in de Product Backlog. De Product Backlog is een geordende lijst met functies of karakteristieken die alle gewenste functionaliteit van het product beschrijven. Volgens de nieuwe scrumguide is de Product Owner de enige persoon die verantwoordelijk is voor het managen van de Product Backlog. Andere betrokkenen kunnen hem daarbij helpen, maar de Product Owner is eindverantwoordelijk. Hij vertegenwoordigt de organisatie en heeft de visie wat het product moet worden. De Product Backlog is het voornaamste middel om die visie over te dragen. De scrumguide zegt niets over de invulling van de Product Backlog en mogelijke technieken die van dienst kunnen zijn bij het beheren ervan. Dit Whitebook geeft een aantal aandachtspunten en hulpmiddelen voor het succesvol beheren van een Product Backlog.

Orde in het detail, tumult in het geheel

Tijdens de Sprint Planning wordt door een Scrum team bepaald welke Product Backlog items in de volgende iteratie worden opgepakt. De items uit de Product Backlog waarmee de teams kunnen starten zijn gedetailleerder en fijnmaziger dan de Product Backlog items waar nog niet mee gestart kan worden. Hoe hoger een item op de Product Backlog des te duidelijker is het doel en de waarde. Tijdens de Sprint Planning worden de items wanneer nodig gesplitst zodat ze haalbaar zijn binnen de iteratie. De ontwikkelteams zijn vaak gericht op de items die binnen een Sprint klaar kunnen zijn. Zij zien daarom over het algemeen vooral gedetailleerde en fijnmazige items. Daarnaast is de Product Backlog een dynamische lijst, waardoor het steeds lastiger wordt om het geheel te overzien. Zelfs voor de Product Owner kan het lastig zijn om aan te geven wat het product nou eigenlijk doet.
Product backlog
Je kunt net als Marc Antoine Laugier zeggen dat er orde is in het detail, maar tumult in het geheel. Wat kunnen we doen om het overzicht in de Product Backlog beter te bewaken?

User Story Mapping

Een techniek die kan helpen bij een duidelijk inzicht in de Product Backlog is User Story Mapping.
User story mapping
Bron: Steve Rogalsky.
Bij User Story Mapping wordt de Product Backlog gestructureerd aan de hand van de belangrijkste bedrijfsactiviteiten of processtappen. In het gegeven voorbeeld zijn dat: Organize Email, Manage Email, Manage Calendar en Manage Contacts. De elementen vormen de ruggengraat van het product. De ruggengraat geeft een compleet overzicht van de scope van het product. Het vertelt als het ware welke mogelijkheden een gebruiker heeft bij het gebruiken van het product. Het zijn de elementaire onderdelen die nodig zijn om tot een zinvol product te komen. Vervolgens kan nog verder gestructureerd worden om het inzicht verder te verbeteren. Zo is Organize Email nog verder verdeeld in twee onderdelen Search Email en File Emails. De ruggengraat of het skelet wordt op de horizontale as weergegeven. Hieronder  worden op de verticale as onder elk onderdeel de Product Backlog items ofwel User Stories in volgorde van belangrijkheid of waarde geplaatst. 

De Product Backlog items tussen de blauwe Release 1 en Release 2 lijn omvatten de minimale functionaliteit die toch het gehele bereik van de ruggengraat afdekt. Van Search by Keyword tot en met Update contact info. Dit deel noemen we het wandelend skelet. Het is de kleinst mogelijke implementatie die de gehele scope van het product afdekt. Alle Product Backlog items die hierna aan het product worden toegevoegd kunnen we zien als vlees op de botten.

Het idee achter het wandelend skelet is geïntroduceerd door Alistair Cockburn. Jeff Paton heeft het meegenomen in User Story Mapping. Met User Story Mapping blijf je een overzicht bewaken tussen de diverse Product Backlog items en het doel dat ze dienen voor de gebruikers. De belangrijkste voordelen van User Story Mapping zijn:

  • Groepeert Product Backlog items die bij elkaar horen;
  • Deelt de Product Backlog items in vanuit een gebruikersperspectief;
  • Geeft een duidelijk inzicht in de waardeketen (Value Chain) aan de hand van de ruggengraat van het product;
  • Geeft een duidelijke context bij het bepalen van prioriteit;
  • Het helpt bij release planning door te waarborgen dat elke release over het gehele bereik van het product functionaliteit toevoegt.

Het belangrijkste is dat het de Product  Backlog zichtbaar is voor iedereen en dat het bijdraagt aan een transparantere en duidelijkere Product Backlog. Net zoals dat de Product Backlog dynamisch is en zich evolueert geldt dit ook voor de User Story Map. Regelmatig onderhoud van de Product Backlog is cruciaal.

Product Backlog onderhoud

Product Backlog onderhoud is een deeltijd activiteit gedurende de Sprint voor de Product Owner en het Ontwikkelteam en bestaat uit het toevoegen van detail, schattingen en volgorde aan de items op de Product Backlog. Mike Cohn en Roman Pichler gebruiken de term DEEP om aan te geven wat de kenmerken zijn van een goede Product Backlog. DEEP staat voor:

  • Detailed Appropriately.
    De Product Backlog items zijn op de juiste manier gedetailleerd. Hoe hoger de prioriteit, hoe gedetailleerder het Product Backlog item uitgewerkt moet zijn.
  • Estimated.
    De Product Backlog items hebben een inschatting van de omvang. Deze schatting kan gebruikt worden bij het bepalen van de invulling van een release of een sprint.
  • Emergent.
    De Product Backlog is dynamisch en verandert met de tijd. Hetzelfde geldt voor de User Story map of elk ander visualisatie mechanisme.
  • Prioritized.
    Er is een volgorde van prioriteit aangebracht. De prioriteit kan bepaald worden op basis van waarde, risico’s en afhankelijkheden.

Een belangrijk hulpmiddel om tot een goede Product Backlog te komen is Product Backlog onderhoud ("grooming"). Dit bestaat uit het toevoegen van detail, toekennen van prioriteit en het schatten van de grootte van de Product Backlog items. Ook al is het geen formele Scrum meeting, wordt er wel geadviseerd om te investeren in Product Backlog onderhoud. Dit zou niet meer mogen zijn dan 10% van de capaciteit van het Ontwikkelteam. In welke vorm en hoe vaak grooming plaats vindt, wordt bepaald door het Scrum Team.

De belangrijkste redenen om Backlog grooming toe te passen zijn:

  • Efficiëntie van het team neemt aanzienlijk toe omdat er minder onduidelijkheid en onzekerheid is;
  • Hoe duidelijker de Product Backlog items, des te beter ze te schatten, te bouwen en te testen zijn;
  • De kennis over het te bouwen systeem wordt gezamenlijk opgebouwd door het gehele team tijdens deze sessies;
  • Doordat de Product Backlog goed voorbereid is en de kennis van de Product Backlog items al aanwezig is, duurt de Sprint Planning meeting veel korter.

Aandachtspunten:

  • Na voorbereiding van Product Backlog items kan de prioriteit verschuiven. Het team kan het gevoel krijgen dat het energie verspild heeft bij het voorbereiden van de Product Backlog items.
  • Als het team druk bezig is om software te bouwen tijdens binnen de iteratie, kan het lastig zijn om al een sprint verder te kijken. Een oplossing hiervoor kan zijn om het zwaartepunt van de voorbereiding later in de iteratie te leggen.

De Product Owner is uiteindelijk verantwoordelijk voor het beheren van de Product Backlog. Het is belangrijk dat hij bij het detailleren van de Product Backlog gebruik maakt van de expertise van anderen. Dat kan zowel technische expertise als domeinkennis zijn. Door iedereen te betrekken bij het onderhouden van de Product Backlog ontstaat er een gezamenlijk begrip over de Product Backlog. Omdat de Product Backlog vanuit verschillende perspectieven wordt benaderd, kan men leren van elkaars benadering. De Product Backlog als brug tussen de business en het ontwikkelteam!

Tot slot

Er valt nog heel veel te zeggen over het beschrijven van de individuele Product Backlog items. Hier kom ik in een ander Whitebook op terug. Een van de belangrijkste uitdagingen is nog altijd het juiste product te bouwen. De Product Backlog speelt hier een cruciale rol in. User Story mapping kan een belangrijke rol spelen in de Product Backlog beter inzichtelijk te maken. Zorg er vervolgens voor dat deze goed zichtbaar is voor iedereen. Er zijn hiernaast nog andere hulpmiddelen bij Product Backlog management. Blijf actief zoeken naar de juiste middelen, die kunnen helpen bij het behouden van een gezonde Product Backlog.

Referenties:

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.