Wat is Product Backlog Refinement?
Product Backlog Refinement is een activiteit waarbij (meestal) de Product Owner een gewenste functionaliteit, idee, epic, .. toelicht aan (een deel van) de Developers zodat er uit deze dialoog een waardevolle oplossing kan beschreven worden.
Backlog Refinement is het uitwerken van de Product Backlog door 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.
Het Scrum Team laat zich leiden door het Product doel (Product Goal). Het is aan de Product Owner om de meest waardevolle Product Backlog Items te identificeren en de backlog op basis hiervan te prioritiseren.
De Product Backlog is dus de roadmap van het Product, waarbij de items bovenaan de Backlog quasi zeker op te nemen zijn, en ook duidelijk zijn naar waarom, wat en hoe ze opgenomen worden. De items onderaan zijn heel wat minder zeker zowel of ze wel waarde zullen toevoegen alsook naar de wat en hoe.
Helemaal ok! Dat is waar het in Scrum om draait: waarde leveren (Transparancy), afstemmen met de markt (Inspect) en de backlog aanpassen (Adapt). Dus we willen niet de details en inschattingen kennen van alle Product Backlog Items want als we een item dan toch niet realiseren, hebben we dit voor niets gedaan (remember, Scrum is ook gebaseerd op Lean principes!)
Naar mate dat de items bovenaan de Product Backlog worden opgenomen, dienen volgende items wel voorbereid te worden om te kunnen opnemen. Daar dient de Backlog Refinement voor!
Idealieter heeft een Scrum Team geen afhankelijkheden met andere teams om hun Product Backlog te realiseren. In heel wat organisaties is dit echter (nog niet) haalbaar. Is er een afhankelijkheid tussen teams? Gebruik de Product Backlog Refinement meeting om inschattingen te bekomen in plaats van adhoc meetings in te plannen. Het timeslot spreek je af met de Product Owner.
Hoe de Product Backlog Refinement plannen?
- De Product Backlog Refinement wordt voorbereid door de Product Owner. Zijn er andere teams die op de Refinement willen langs komen, dan spreken ze het tijdslot af met de Product Owner.
- Plan de Product Backlog Refinement meeting wekelijks in, op een vaste dag en tijdstip. Vermijd de dagen van Sprint Planning en Sprint Review. In de meeste organisaties zien we de Refinement op woensdag of donderdag gebeuren.
- Start met een refinement van 2 uur, wekelijks. Bespreek in de Sprint Retrospective of meer tijd nodig is.
- De Product Owner zorgt voor het annuleren van de Refinement indien deze die week niet nodig is.
- Worden er Product Backlog Items (PBIs) in detail besproken om vrij snel te realiseren? Dan zijn alle Developers er best bij. Wordt er advies gevraagd over een idee, dan vaardigen de Developers best iemand van hun af om hierover met de Product Owner in overleg te gaan. (Blijf het lean houden, zaken die nog onzeker zijn, hoeven nog niet door het ganse team uitgedokterd worden).
Wat is de rol van de Scrum Master tijdens de Refinement?
Het process dat we vaak toepassen in organisaties en teams die nieuw zijn in hun Scrum Adoptie is deze van Stephan van Rooden, zoals beschreven in hun blogpost op scrum.org. Het beschrijft een mogelijke kadans om richting een productieve en positieve meeting.
Als Scrum Master bewaak je de timebox. We starten met 10 minuten, waarin de Product Owner het Product Backlog Item (PBI) toelicht. Is het duidelijk voor de Developers waarom dit waarde levert en waarover het gaat? Dan bespreken de Developers hoe ze het PBI zullen realiseren.
Dit is een moment voor de Scrum Master om de timebox in de gaten te houden: Zijn de 10 minuten voorbij maar voelt het team dat ze er bijna zijn? Great! Vraag aan het team of ze de volgende 10 minuten wil gebruiken om hun brainstorm af te ronden of ze willen overgaan naar de volgende stap (inschatting van complexiteit). Of, is het door de brainstorm duidelijk dat er huiswerk is voor de Product Owner? Zoja, stel voor om de PBI te parkeren en over te gaan naar het volgende item.
Daarnaast ben je als Scrum Master ‘advocaat van de duivel’ tijdens deze meeting: Zijn de Developers wel zeker dat ze de Wat en Waarom begrijpen? Is de inschatting van complexiteit en dus kost in overeenstemming met de verwachte Value? Grijpt het team niet te snel naar een Spike .. of misschien te snel?
Als Scrum Master begeleid je de deelnemers om kennis uit de groep te halen, naar elkaar te luisteren en tot een gedragen aanpak te komen en zorg je voor empirisch denken: “Hebben we al iets gelijkaardig gedaan in het verleden? Hoe helpt die kennis ons voor dit nieuwe item?”
Deze processflow is uitermate geschikt om kadans in de Backlog Refinement te houden. Door te timeboxen per 10 minuten en actief te bevragen, zorg je als Scrum Master voor een positieve en productieve meeting.
Idealiter ben je als Scrum Team onafhankelijk van andere teams om je Backlog te realiseren. In veel organisaties is dit echter (nog) niet haalbaar. De Product Backlog Refinement meeting kan dan ook gebruikt worden als het moment voor andere teams om met hun feature requests (afhankelijkheden) naar het team te komen om een inschatting te verkrijgen, in plaats van willekeurige meeting in te plannen.
Een reactie
[…] Sprint Planning van 4 uur. Waarschijnlijk kan die korter, zeker als je al een goed uitgewerkte Product Backlog Refinement houdt. Gebruik de Sprint Retrospective om bij te sturen! Sprint Planning organiseer je 1x per […]