Speciaal voor u. Omdat wij ervan overtuigd zijn dat kennis pas echt waardevol is als je het deelt. De Product Backlog. Hoe ga je daar mee om?

Transcriptie

1 Speciaal voor u. Omdat wij ervan overtuigd zijn dat kennis pas echt waardevol is als je het deelt. De Product Backlog Hoe ga je daar mee om? Kevin Bakker Baarn, Met hulp van: Frank Sprengers, Ide Koops, Jaap Schuttevaer, Jasper Verwaters, Joost Janssen, Maroen de Haan en Sanne Gillissen V2.1

2 Inhoud 1 Inleiding De rollen Product Owner Scrum-Team Definition of Ready Product Backlog is DEEP Detailed appropriately Estimated Emergent Prioritized INVEST een Story Independent Negotiable Valuable Estimable Small Testable Voldoen aan INVEST De Refinement-sessie Voorbeelden bij de Story Risico s De planning User Story Mapping Bijlage 1. Splitsen van een story Bijlage 2. Referenties KZA, Baarn 2 van 16

3 1 Inleiding De Product Backlog is de backbone van de werkzaamheden voor een Scrum-project. Een goede backlog zorgt er voor dat het team weet welke resterende werkzaamheden er nog zijn voor het product. Vrijwel ieder Scrum-project maakt gebruik van een Product Backlog. In de officiële Scrum Guide is de Product Backlog omschreven als een lijst met alle kenmerken, functies, requirements, verbeteringen en foutherstel die samen de veranderingen beschrijven die aan het product zullen worden gedaan in toekomstige releases. De items op de Product Backlog worden meestal weergegeven als user stories. De user stories beschrijven wat en waarom de klant deze functionaliteit wil hebben. User stories worden als volgt geschreven: Als (gebruiker), wil ik (feature), zodat ik (reden waarom / achterliggende behoefte). Het opstellen van een goede backlog is vaak nog een uitdaging. Hoe zit het met de verantwoordelijkheden? Hoe prioriteer je de items? Wat zet je nu wel en niet in een item? In dit document geef ik antwoord op deze vragen. 2 De rollen De rollen Product Owner en Scrum-team zijn de belangrijkste rollen in dit document. 2.1 Product Owner De Product Owner (PO) is verantwoordelijk voor het bijhouden van de Product Backlog, door het vertegenwoordigen van de belangen van alle stakeholders. Tevens is de PO verantwoordelijk voor het maximaliseren van de waarde van hetgeen het development team oplevert. De PO is één persoon, geen comité. 2.2 Scrum-Team Het team is multidisciplinair en zelfsturend. Dat betekent dat het team zelfstandig in staat is alle taken van ontwerp, realisatie, testen tot en met de oplevering te verzorgen. Het team bestaat doorgaans uit 5 tot en met 9 deelnemers. Het team is verantwoordelijk voor zowel het inplannen als het uitvoeren van het werk tijdens een Sprint. KZA, Baarn 3 van 16

4 3 Definition of Ready Aangezien Scrum-teams binnen een x aantal weken (vaak 2 of 3) werkende software moeten opleveren, is het noodzakelijk dat we alleen werk oppakken dat ook echt afgemaakt kan worden. Het team werkt alleen aan dat wat af kan komen en veel waarde toevoegt. Om dit te realiseren werken Scrum-teams met een lijst van criteria waarop staat of werk helder genoeg is. Deze lijst noemen we de Definition-of-Ready (DoR). Door het gebruik van een DoR zorgen we er voor dat de kans op het opleveren van de gewenste software toeneemt. Wanneer iedereen de story volledig begrijpt gaat het inschatten beter. De kans op miscommunicatie tijdens de sprint tussen teamleden en PO neemt af. De opgeleverde functionaliteit zal voldoen aan de gevraagde kwaliteit zolang we ons aan de story houden. Het team bepaalt of de items bovenaan de backlog Ready zijn. Waar de PO na afronding van een item kijkt of het Done is. Een Product Backlog is niet hetzelfde als een traditionele lijst met SMART requirements. De belangrijkste kenmerken van een goede Product Backlog kunnen we samenvatten met de acroniemen DEEP en INVEST. DEEP en INVEST zullen in de volgende hoofdstukken de aandacht krijgen. Door de backlog minimaal voor 1 ½ sprint redelijk in detail uitgewerkt te hebben kan je als team rekening houden met wat komen gaat. Tijdens de planningssessie is de focus vooral op hoe het gedaan wordt en minder op wat gedaan wordt. Onderstaande afbeelding geeft de cyclus weer om tot Ready items te komen. KZA, Baarn 4 van 16

5 4 Product Backlog is DEEP Een Product Backlog is niet hetzelfde als een traditionele lijst met SMART requirements. De belangrijkste kenmerken van een goede Product Backlog heeft Mike Cohn samengevat in het acroniem DEEP. De volgende paragrafen gaan verder in op het acroniem DEEP: Detailed appropriately, Estimated, Emergent en Prioritized. Deze punten helpen om tot een kwalitatief goede backlog te komen. Denk altijd aan het volgende: Hoe DEEP is onze Product Backlog. 4.1 Detailed appropriately De items op de Product Backlog hebben het juiste detailniveau. De items die in de komende sprint door het Scrum-team worden opgepakt en geïmplementeerd, zijn klein. De items die niet de komende sprints worden opgepakt zijn nog minder ver in detail uitgewerkt. Het is onverstandig om allemaal gedetailleerde user stories op de Product Backlog te zetten. Dat is lastig te managen, is onoverzichtelijk, leidt tot veel rework en het inschatten en prioriteren van al die kleine user stories kost veel tijd. Kortom te veel details op de Product Backlog is verspilling van tijd en energie (waste). Het advies is dan ook: Voeg details toe op het laatste verantwoordelijke moment. Tijdens de laatste Refinement-sessie (zie hoofdstuk 6 voor meer info) of het eerste deel van de planningssessie kunnen de laatste details toegevoegd worden. Stories die bij de planning besproken worden zijn al (zo goed als) klaar. Te veel details op de Product Backlog is verspilling van tijd en energie (waste). 4.2 Estimated De omvang van de stories is voor de komende sprints ingeschat. Hoe verder op de backlog hoe grover geschat mag worden. KZA, Baarn 5 van 16

6 Het gaat om een relatieve schatting; niet om de tijd die nodig is om een user story te realiseren binnen de sprint. Het team schat in hoe groot een user story is in vergelijking met een aantal referentie user stories. Bijvoorbeeld anderhalf keer zo groot, tien keer zo groot. Ieder user story krijgt een aantal punten. Aangezien deze punten relatief zijn en daardoor geen grootheid hebben, worden ze meestal aangeduid als story points. De schattingen zijn belangrijk omdat de Product Backlog onder andere dient als planningstool. In de Product Backlog is namelijk eenvoudig aan te geven welke user stories in een sprint en in een release meegenomen kunnen worden. Blijf de Product Backlog inschatten van hoog over naar details. 4.3 Emergent De Product Backlog evalueert. De Product Backlog is dynamisch in de zin dat deze voortdurend verandert om te kunnen weerspiegelen wat er nodig is om het product waardevol, concurrerend en beter te maken. De Product Backlog is dan ook nooit af. De PO en het team passen de user stories, de prioriteiten en de schattingen voortdurend aan op basis van de laatste inzichten. Die inzichten veranderen doordat je steeds meer te weten komt over het product, de gebruikers, de omgeving en de technologie en doordat de mening en behoeften van de stakeholders aan voortschrijdend inzicht onderhevig zijn. De Product Backlog is niet statisch. Blijf mee gaan met de verandering. KZA, Baarn 6 van 16

7 4.4 Prioritized De items op de Product Backlog staan in volgorde van prioriteit. De user story met de hoogste prioriteit staat bovenaan en wordt als eerste geïmplementeerd. De PO kent de prioriteiten toe, maar laat zich adviseren door stakeholders uit de business en door het team. Aspecten die meespelen bij het prioriteren van de user stories zijn: minimum marketable features, business value, risico's en afhankelijkheden. Prioritering is essentieel voor het leveren van zo veel mogelijk business value. De PO is verantwoordelijk voor het maximeren van de Return on Investment (ROI). Prioritering is essentieel voor het leveren van zo veel mogelijk business value. KZA, Baarn 7 van 16

8 5 INVEST een Story Met behulp van INVEST kunnen de stories vanuit zes oogpunten bekeken worden. Elke story zal aan de INVEST moeten voldoen. Schort het aan één van de INVEST onderdelen, of blijkt er geen overeenstemming te zijn tussen de PO en het team, dan moet de story terug naar de tekentafel! 5.1 Independent Is de user story onafhankelijk (Independent) te realiseren en te implementeren? Afhankelijkheden met andere user stories betekent dat de user story niet los op te leveren is binnen een sprint. Daardoor kan de user story bijvoorbeeld niet voldoen aan de definition of done. 5.2 Negotiable Is de user story onderhandelbaar (Negotiable)? Is het verder in detail uit te werken met behulp van de klant of business? Een user story moet ruimte bieden tot onderhandeling, het gaat hier om de essentie, niet de details. 5.3 Valuable Heeft de user story waarde (Valuable) voor de klant en de beheerders? De afspraak is tenslotte dat alleen die user stories ontwikkeld worden die waarde toevoegen voor de klant. 5.4 Estimable Kan het team een gedragen inschatting (Estimate) maken van het werk om deze user story te realiseren? Als dat niet het geval is, dan kan de user story veel te groot zijn, een zogeheten epic. Een epic kan vervolgens worden opgesplitst in meerdere user stories. KZA, Baarn 8 van 16

9 Zie bijlage 1 voor grotere afbeelding. 5.5 Small Is de user story klein (Small) genoeg? Een user story is klein genoeg als het een dagdeel tot (maximaal) enkele dagen tijd kost voor een team om deze te realiseren. 5.6 Testable Als laatste de controle of het ook een testbare (Testable) user story is. Door al te weten wat er concreet anders is na realisatie van de user story en hiervoor acceptatiecriteria te definiëren controleer je of de verwachtingen voor de user story tussen de PO en het team overeenkomen. Benoem in de story al een aantal testscenario s. 5.7 Voldoen aan INVEST Door gebruik te maken van de INVEST schaal kan er effectief gemeten worden of de user story voldoet aan het INVEST principe. Maak een tabel met daarin de stories die bovenaan de backlog staan. Zet de INVEST in de kolommen naast de stories. Laat het team samen met de PO de tabel invullen. De schaal is als volgt: 1 Absoluut niet 2 Waarschijnlijk niet 3 Misschien 4 Bijna duidelijk 5 Absoluut duidelijk KZA, Baarn 9 van 16

10 Voorbeeld: Story Independent Negotiable Valuable Estimable Small Testable Totaal Omschrijving Omschrijving Wanneer de score < 18 is de story niet onafhankelijk genoeg. Kies er in dat geval voor om de story verder uit te werken of op te knippen. 6 De Refinement-sessie Een belangrijk hulpmiddel om tot een goede Product Backlog te komen is tijdens de Product Backlog onderhoud sessie oftewel Refinement-sessie. 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, het advies is wel om te investeren in Product Backlog onderhoud. De frequentie van de sessie bepaalt het Scrum team. Het volledige Scrum team en de PO nemen deel aan deze sessie. De belangrijkste redenen om het toe te passen zijn: Challenge the story : Waarom is dit nodig? Wat als we het niet doen? Kan het ook anders? Maak het tastbaar door voorbeelden op te stellen, dit helpt om de story echt te begrijpen. Werk de acceptatie criteria uit. Efficiëntie van het team neemt aanzienlijk toe omdat er minder onduidelijkheid en onzekerheid is; Hoe duidelijker de 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 items al aanwezig is, duurt de Sprint Planning meeting veel korter. KZA, Baarn 10 van 16

11 6.1 Voorbeelden bij de Story Hierboven benoemde ik al Stel een paar voorbeelden op. Het kan zijn dat wat de één denkt niet overeen hoeft te komen met hoe een ander het interpreteert. Hieronder een situatie waarbij het zal helpen als de PO voorbeelden geeft. Wason vond in 1966 dat nog geen 10% van de respondenten het correcte antwoord noemt. In 1993 werd dit resultaat gerepliceerd. Dit kan natuurlijk ook voorkomen bij user stories. In bovenstaand voorbeeld begreep maar 10% wat de PO nu echt bedoelde. Als de PO een paar voorbeelden zal geven, dan is de kans op verkeerde interpretatie aanzienlijk afgenomen. Wil je je antwoord toetsten? Stuur je antwoord en argumentatie op naar en wij zullen aangeven of het goed is. 7 Risico s Voordat het echte plannen kan starten tijdens de planningssessie is het belangrijk dat de risico s zijn ingeschat en genoteerd. Risico s bepalen de diepgang van de testuitvoer van unit-testen tot acceptatietesten. Hoe hoger het risico des te meer tijd zal er voor de story nodig zijn. De PO kan bij het aanmaken van de story al aangeven wat de impact is en de risico s bij de story noteren. Tijdens de Refinement-sessie kan de PO zijn keuze voor het risico toelichten waar nodig en kan er gezamenlijk met het team verdere risico s benoemd worden. KZA, Baarn 11 van 16

12 Het team bepaald, eventueel in overleg met PO, tijdens de Refinement-sessie of eerste fase van de planningssessie de faalkans van de story. De impact x faalkans = risico. Afhankelijk van het risicogebied worden de maatregelen gekozen. Naast het bepalen van de risico s is het ook goed om na te denken over de tegenmaatregelen om de risico s te beheersen. Op deze wijze vergroot je de oplevering van kwalitatieve goede software. De teststrategie cq. tests zullen terug te leiden moeten zijn naar de geformuleerde risico s. 8 De planning De Product Backlog voldoet nu aan DEEP en de stories zijn INVEST. De laatste afstemmingen met de PO vinden plaats in het eerste deel van de meeting. Het tweede deel gebruikt het Scrum team om de backlog items in te schatten tot waar het team denkt dat haalbaar is om af te krijgen aan het einde van de sprint. Het zal niet meer mogen zijn dat er blokkerende afhankelijkheden zijn. Is dit wel het geval, overweeg dan om het item terug te zetten op de backlog. KZA, Baarn 12 van 16

13 9 User Story Mapping Een techniek die kan helpen bij een duidelijk inzicht in de Product Backlog is User Story Mapping. 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 , Manage , 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 nog verder verdeeld in twee onderdelen Search en File s. 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. KZA, Baarn 13 van 16

14 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 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. KZA, Baarn 14 van 16

15 Bijlage 1. Splitsen van een story KZA, Baarn 15 van 16

16 Bijlage 2. Referenties DEEP Mike Cohn INVEST William (Bill) Wake Scrum Ken Schwaber & Jeff Sutherland Story Mapping Alistair Cockburn & Jeff Patton KZA, Baarn 16 van 16