Fabel: we moeten pre-refinement doen om Succesvol onze Sprint te kunnen plannen
Er is slechts één soort Product Backlog refinement
Product Backlog Refinement
Fabel: we moeten pre-refinement doen om succesvol onze Sprint te kunnen plannen
In deze serie "Feit of Fabel" blogposts nemen we de Sprint Planning onder de loep. Wat zijn de ingrediënten voor een succesvolle Sprint Planning? Is "pre-refinement" echt nodig om van de Sprint Planning een succes te maken? En wat houdt Product Backlog refinement precies in binnen Scrum? We duiken er samen in.
De stelling van deze blog suggereert dat er een specifiek moment in de Sprint is waarop je de Product Backlog Items (PBI’s) verfijnt. Binnen Scrum kennen we vijf "events" die ons helpen om een "Done" increment op te leveren. De Scrum Guide beschrijft de volgende vijf events:
- De Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Het verfijnen ("refinen") van de Product Backlog (Product Backlog refinement) is niet een van deze vijf officiële Scrum-events. Waar en wanneer doe je als Scrum Team dan dit werk? Als je de Scrum Guide leest, zul je de term slechts één keer tegenkomen, in de paragraaf over de Product Backlog.
Wat is Product Backlog Refinement?
"Het uitwerken van de Product Backlog is het verkleinen en verder definiëren van Product Backlog items. Zo ontstaan er kleinere, meer nauwkeurige items. Dit is een doorlopende activiteit. Hierbij voegen we details toe zoals een beschrijving, volgorde en grootte. De attributen verschillen vaak per domein van het werk. De Developers die het werk doen zijn verantwoordelijk voor het inschatten van de grootte. De Product Owner mag de Developers hierin beïnvloeden. Dit doet hij door ze te helpen bij het begrijpen en selecteren van afwegingen."
Wat we hieruit kunnen leren, is dat Product Backlog refinement een doorlopend proces is. Het is dus niet één specifiek moment in de Sprint. We hoeven de backlog niet op één vast moment bij te werken. En dat is logisch. Het kan namelijk best zijn dat je items gedurende de Sprint moet aanpassen. Denk aan nieuwe omstandigheden, technologische ontwikkelingen of andere factoren.
Een ander belangrijk punt is dit: het Scrum Team beslist zelf hoe en wanneer de Product Backlog refinement plaatsvindt.
De Product Owner is er verantwoordelijk voor dat de Product Backlog Items duidelijk en zichtbaar zijn op de backlog, en dat ze helder genoeg zijn voor de Developers.
De Developers verfijnen de items vervolgens verder naar taken en acties om tijdens de Sprint een 'Done' Increment te kunnen opleveren.
Wil je hier elke dag dertig minuten aan besteden? Dat is prima. Plan je liever één sessie van vier uur per Sprint? Ook goed! Het komt neer op het zelfsturende vermogen van het Scrum Team. Het heeft daarnaast weinig zin om veel tijd te steken in items die onderaan de backlog staan; Scrum draait immers om just-in-time planning.
Refinement in Sprint Planning
Nu we weten dat het Scrum Team de vrijheid heeft om zelf te bepalen hoe en wanneer de Product Backlog refinement plaatsvindt, moeten we eens kritisch kijken naar de Sprint Planning. Is het mogelijk om een deel van de refinement tijdens de Sprint Planning te doen? Laten we kijken welk advies de Scrum Guide ons hiervoor biedt:
"De Product Owner verzekert zich ervan dat de aanwezigen voorbereid zijn om de meest belangrijke Product Backlog items en hoe deze zich verhouden tot het Product Doel te bespreken. Het Scrum Team mag ook anderen uitnodigen om de Sprint Planning bij te wonen als adviseur."
Nu zien we dat er tijdens de Sprint Planning nog steeds ruimte is voor Product Backlog refinement. We hoeven niet alles tot in de puntjes uitgewerkt te hebben vóór de Sprint Planning begint, simpelweg omdat het werk voortdurend aan verandering onderhevig is.
Product Backlog refinement heeft een grote invloed op je Sprint Planning, maar wanneer is die planning nu echt succesvol? Naar mijn mening is dat wanneer het Scrum Team erin slaagt een goed Sprint Doel op te stellen en er genoeg werk is verfijnd voor de eerste paar dagen van de Sprint, gebaseerd op empirische data over wat het team daadwerkelijk kan verzetten.
Samenvatting
Laten we het afronden: we hebben geen vast "pre-refinement" moment nodig; het is een continu proces tussen de Product Owner en de Developers. Om succesvol te zijn, kun je zelfs tijdens de Sprint Planning nog verfijnen. De stelling is dus inderdaad een fabel.
Een succesvolle Sprint Planning gebruikt de Product Backlog (zo ver uitgewerkt als op dat moment nodig is) als input, is een samenwerking van het hele Scrum Team (en eventuele andere betrokkenen indien nodig) en heeft een krachtig Sprint Doel als resultaat.
Dit artikel is geschreven door ons Scrum Facilitator Community lid Erwin van Maren, geredigeerd door Scrum Facilitator Jasper Alblas.
Als creatieve en ervaren Agile Professional leef ik voor alles wat met Agile, Scrum, leiderschap en teams te maken heeft. Denk aan de rollen van Trainer, Coach, Scrum Master en Product Owner. Ik verzorg interactieve en betekenisvolle Scrum-trainingen. Mijn persoonlijke streven is om dit 100% slide-vrij te doen. Mijn kracht ligt in het faciliteren van eerlijke en open gesprekken. En ik daag mezelf uit om elke dag een beetje beter te worden.
Na mijn loopbaan bij de krijgsmacht maakte ik de overstap naar web- en app-ontwikkeling. Dit deed ik als Scrum Master en Product Owner. Mijn ervaringen en interesses zijn breed. Maar de kern ligt altijd bij leiderschapstraining, coaching, Agility, ondernemerschap, (geo)politiek en sport.
Ik krijg energie van het empoweren van teams. Ik laat ze groeien in hun skills. Dit doe ik door teamleden uitdagende taken en prikkelende vragen voor te schotelen. Hierbij combineer ik mijn defensie-ervaring op het gebied van teambuilding met de nieuwste Agile-inzichten. Ik geloof heilig in de Scrum-werkwijze. Ik werk zij aan zij met het team. Want het is de teamprestatie die het succes bepaalt!