samen
werken
Hoe kan ik Product Backlog Refinement aanpakken?
Product Backlog refinement is niet als apart event gedefinieerd binnen het Scrum framework. Echter, goede Product Backlog refinement verlaagt het risico dat werk niet opgeleverd kan worden gedurende een sprint. Uit de Scrum guide kan de volgende definitie worden afgeleid voor Product Backlog refinement:
“Het uitwerken van de Product Backlog (‘refinement’) is het verkleinen en verder definiëren van Product Backlog items in kleinere, meer nauwkeurige items. Dit is een doorlopende activiteit om details zoals een beschrijving, volgorde en grootte toe te voegen.”
Activiteiten tijdens Product Backlog refinement.
Product Backlog refinement is volgens Simon Flossmann (Professional Scrum Master via Scrum.org) op te delen in de volgende stappen:
- Vergroten van het inzicht in het werk dat gedaan moeten worden;
- Prioriteren van de items die op de Product Backlog staan;
- Inschatten van de omvang van de items die op de Product Backlog staan;
- Kleiner maken van de Product Backlog items.
1. Vergroten van het inzicht in het werk dat gedaan moeten worden
Succesvolle Scrum teams beginnen niet met zo maar de implementatie van features. Ze beginnen met inzicht te krijgen in de problemen van de klant en onderzoeken mogelijke oplossingen daarvoor.
Een werkvorm om inzicht te krijgen in de behoefte van de klant, is de Liberating Structure werkvorm, ‘User Experience Fishbowl’. In deze werkvorm heb je 2 groepen: de Stakeholders en het Scrum team. Vervolgens wordt de volgende werkvorm doorlopen:
- De Stakeholders bespreken hun behoeften, i.r.t. User Stories die op de Product Backlog staan, aan de hand van de volgende vragen: “Stel je voor dat deze feature/functionaliteit al onderdeel was van het product; hoe, wanneer en waarom zou je het gebruiken. Welke stappen doorloop je bij het gebruik? Waarom is het nuttig? Wat zou maken dat het minder bruikbaar is?”
- Het Scrum team volgt het gesprek; Vervolgens bespreekt het Scrum team wat ze hebben gehoord en formuleert het nieuwe vragen die in een nieuwe ronde worden voorgelegd aan de Stakeholders.
Deze werkvorm geeft inzicht in de waarde die een feature/functionaliteit heeft voor de stakeholder en daarmee helpt het om grote stukken werk van de Product Backlog, op te delen in kleinere stukken die nog steeds waardevol zijn voor de stakeholders.
2. Prioriteren van de items die op de Product Backlog staan
Het prioriteren van items op de Product Backlog is primair een activiteit van de Product Owner. Echter, deze heeft hierbij de hulp nodig van de Stakeholders en het Scrum team. Naast een gedragen prioritering levert dit ook inzichten op over de features die echt waarde opleveren voor de Stakeholders.
Onderstaande werkwijze betrekt de Stakeholders maximaal bij het bepalen van de prioriteit van de items op de Product Backlog.
- Ieder item op de Product Backlog wordt op een aparte kaart genoteerd;
- De kaarten worden geschud en als stapel, ondersteboven, op een tafel gelegd;
- De kaart die bovenop ligt wordt omgedraaid en als referentiekaart naast de stapel met kaarten gelegd;
- De volgende kaart wordt van de stapel gepakt en de stakeholders geven aan of deze belangrijker of minder belangrijk is dan de referentiekaart die op tafel ligt. Afhankelijk van de uitkomst wordt de kaart onder of boven de referentiekaart gelegd;
- Alle kaarten van de stapel doorlopen dit proces.
Na afloop is er een helder overzicht van de prioriteit die de stakeholders aan de verschillende items geven.
3. Inschatten van de omvang van items die op de Product Backlog staan
Het doel van het inschatten van de omvang van de items op de Product Backlog, is om een duidelijke inschatting te krijgen van de omvang van de totale hoeveelheid werk. Hierbij wordt de omvang relatief ingeschat ten opzichte van andere items die op de Product Backlog staan of items die in het verleden zijn gerealiseerd.
In veel gevallen wordt ‘planning poker’ gebruikt als werkvorm om de omvang van Product Backlog items in te schatten. De werkvorm ‘magic estimation’ is hiervoor een alternatieve werkvorm.
- Voor het aangeven van de omvang van een item, maken we gebruik van de Fibonacci reeks 1,2,3,5,8,13,21 aangevuld met een vraagteken (?);
- Een willekeurig item van de Product Backlog wordt door alle Developers tezamen voorzien van een inschatting (cijfer uit de Fibonacci reeks). De inschatting van dit item dienst als referentie voor het vervolg;
- De overige items worden verdeeld onder de Developers;
- De Developers geven het item dat hen werd toegewezen een getal uit de Fibonacci reeks die de omvang weergeeft in relatie tot het referentie item. Als iemand het item niet begrijpt wordt een vraagteken geplaatst;
- Wanneer alle items zijn voorzien van een inschatting, dan bekijken alle Developers de inschattingen van alle items. Als zij het niet eens zijn met de inschatting(en) op een kaart, voegen zij hun eigen inschatting toe;
- In het geval dat er voor een item geen eensluidende inschatting gemaakt kan worden, kan het item besproken en eventueel verder worden toegelicht door de Product Owner. Als de waardes dicht bij elkaar liggen, kan er voor worden gekozen om de waarde tussen de verschillende inschattingen te nemen. Bij een vraagteken voor een kaart vindt er aanvullende verduidelijking plaats door de Product Owner.
Het resultaat is een inschatting van alle items op een Product Backlog ten opzichte van een referentie item.
4. Kleiner maken van Product Backlog items
Product Backlog items worden kleiner gemaakt om enerzijds te zorgen dat ze in één sprint opgeleverd kunnen worden, anderzijds zorgt dit voor items die direct waarde toevoegen bij oplevering.
Het kleiner maken van items kan op de volgende manieren:
- Als een item bestaat uit opeenvolgende stappen (een workflow), dan kan deze worden opgedeeld op basis van de stappen in de workflow.
- Een item dat beschrijft dat een klant kan betalen voor de artikelen in de elektronische boodschappenmand, kan als volgt worden opgedeeld:
- Als een klant kan ik inloggen
- Als een klant kan ik betalen voor mijn bestelling
- Als een klant ontvang ik een bevestiging via mail van mijn bestelling
- Een item dat beschrijft dat een klant kan betalen voor de artikelen in de elektronische boodschappenmand, kan als volgt worden opgedeeld:
- Functionaliteit bestaat vaak uit stappen die in de meeste gevallen aan de orde zijn (de happy-flow) en de stappen die bij uitzondering worden gebruikt (unhappy flow). Items kunnen conform de happy-flow en unhappy-flow, kleiner worden gemaakt.
- Het item dat beschrijft dat een klant kan inloggen kun je als volgt kleiner maken:
- Happy-flow : Als een klant kan ik inloggen met mijn account;
- Unhappy-flow : Als het niet lukt om in te loggen kan ik mijn account resetten.
- Het item dat beschrijft dat een klant kan inloggen kun je als volgt kleiner maken:
Het belang van Product Backlog refinement
Zoals we vooraf al constateerden is Product Backlog refinement niet als apart event gedefinieerd binnen het Scrum framework. Het vindt plaats als onderdeel van de Sprint Planning maar ook in speciaal daarvoor opgezette workshops. Product Backlog refinement geeft inzicht in hetgeen geleverd gaat worden en de daarmee samenhangede waarde, wat de omvang van het werk is en het belang van de verschillende items. Goed Product Backlog refinement is een randvoorwaarde om succesvol sprints te realiseren.
Bronvermelding: Simon Flossmann
Wil je eens doorpraten met een van onze ervaren coaches of trainer’s over wat Scrum voor jou kan doen? Neem contact op via 020 2614 195 of info@agilescrumgroup.nl en we plannen vrijblijvend wat in.
Ook interessant:
- Agile Coach Toolkit
- Een Kanban bord maken in 5 stappen
- Positieve psychologie
- Kun je een Retrospective wel eens overslaan?
