Tip: in dit blog gebruik ik een heleboel Scrum-termen. Daarom vind je onderaan dit blog een begrippenlijst met alle Scrum-termen.
Met Scrum realiseer je op een flexibele manier en binnen een vooraf bepaald tijdsbestek het best haalbare product. In korte Sprints van 2 a 3 weken werkt een multidisciplinair team parallel aan elkaar aan een set wensen. Deze wensen noemen we user stories: een specifieke wens op basis van een afgekaderde functionaliteit van het product. De user stories worden verzameld in een Product Backlog en aan elke user story wordt business value toegekend. Tijdens een Sprint worden de user stories op volgorde van business value opgepakt. De Product Backlog is Sprint overstijgend: bij een volgende Sprint is de (herziene) backlog nog steeds het uitgangspunt.
Wat is de Product Backlog Refinement?
Elke Sprint bevat een vaste set Scrum-events, zoals de Product Backlog Refinement, om aan de pijlers van Agile te kunnen voldoen: transparantie, inspectie en aanpassen. Oftewel: is alles helder, hebben we het op de gewenste manier gerealiseerd en moeten we op basis van de kennis die we nu hebben dingen aanpassen? Tijdens de Refinement wordt de Product Backlog doorlopen en de gewenste werking van de functionaliteiten uitgediept. Het doel is het verfijnen van de user stories, zodat voor het Scrumteam duidelijk is wat er gedaan moet worden om de user story af te ronden. Dit betekent dat de Product Backlog wordt verrijkt en aangevuld met informatie die het Scrumteam nodig heeft om de complexiteit van een user story in te schatten en de user story te realiseren. Waar nodig worden user stories opgesplitst om ze werkbaar te maken. Een goede Refinement zorgt voor een soepele Sprint Planning en vindt enkele dagen voor deze Sprint Planning plaats. Het Scrumteam heeft zo nog voldoende tijd om zaken uit te werken en te verifiëren. De Scrum Guide - een document dat de Scrum-methodiek uitlegt - bevat geen duidelijke omschrijving over de manier waarop de Refinement zou moeten plaatsvinden. Het Scrumteam bepaalt hoe en wanneer de Refinement plaatsvindt. In sommige gevallen is dit een doorlopend proces en in andere gevallen losse events die na elke Sprint plaatsvinden. In de rest van dit blog licht ik toe hoe we dit bij Netvlies aanpakken.
Hoe werkt de Product Backlog Refinement?
Bij de Refinement zijn het development team, de Scrum Master en de Product Owner aanwezig. De Product Owner (PO), dit is een afgevaardigde van de klant die onderdeel uitmaakt van het Scrumteam, schrijft de user stories en bepaalt de business value. Tijdens de Refinement legt de PO de user stories een voor een uit aan het development team. Een user story kan ondersteund worden door onder andere flowcharts, wireframes of designs. Die helpen het Scrumteam om een vollediger beeld te krijgen. Als we al één of meerdere Sprint hebben afgerond, pakken we ook de acceptatieomgeving erbij. Door vanuit elke discipline vragen te stellen, voegt het Scrumteam details toe aan de user stories. Daarnaast bespreken we welke functionaliteiten nodig zijn om de user story te realiseren en wat de beste manier is om de user story te realiseren. Dit helpt ook om inzicht te krijgen in afhankelijkheden, bijvoorbeeld tussen user stories onderling of een koppeling met een ander systeem die moet worden aangepast. De PO vult ter plekke de Product Backlog verder aan. De Scrum Master bewaakt het proces, checkt of de user story voor iedereen duidelijk en compleet is en zorgt indien nodig dat acties aan de user story gekoppeld worden, bijvoorbeeld het verfijnen van een design of uitzoeken van technische mogelijkheden.
Behapbare user stories
Tijdens de Refinement wordt duidelijk of een user story te groot (of soms zelfs te klein) is. In dat geval moet een user story opgesplitst worden in behapbare delen die afzonderlijk van elkaar ontwikkeld kunnen worden. De voordelen van het opsplitsen van een te grote user story licht ik toe aan de hand van een voorbeeld:
De PO heeft de volgende user story geformuleerd: “Als bezoeker wil ik via een formulier contact op kunnen nemen met de klantenservice, zodat ik mijn vraag over X kan stellen.” Dit betekent dat een formulier moet worden gebouwd en dat dit formulier op bepaalde pagina’s moet worden geplaatst. Bij een formulier hoort ook een melding (op de huidige pagina) dat het formulier correct is ingevuld, een bedankpagina met de bevestiging dat het formulier correct is ingevuld of een bevestigingse-mail. Voor deze meldingen moeten teksten worden geschreven, de data uit het formulier moet ergens worden opgeslagen en het formulier moet kunnen worden doorgemeten door een marketeer. Achter het invullen van een formulier zit dus nog een hele flow. Door die flow op te delen in losse user stories heeft de PO de mogelijkheid om te spelen met de prioriteiten, is de status en voortgang van het project beter inzichtelijk en kunnen de losse onderdelen in theorie aan het einde van de Sprint afzonderlijk van elkaar live. Daarnaast zijn de user stories los te testen, waardoor eventuele foutjes er eerder uitgehaald kunnen worden. Zo voorkom je dat je aan het eind vele stappen terug moet doen die wellicht gevolgen hebben voor de hele flow van het formulier.
Het is zonde om alle user stories uit de Product Backlog in één keer te refinenen, omdat gedurende de Sprints inzichten, prioriteiten en de scope kunnen veranderen en user stories worden aangepast of volledig vervallen. Daarom worden alleen de user stories met de hoogste business value besproken. Dit komt neer op werk voor 1 a 2 Sprints.
Voorbereiden van de Product Backlog Refinement
Ter voorbereiding op de Product Backlog Refinement controleert de PO of de prioritering klopt, zodat tijdens de Refinement de belangrijkste user stories besproken worden. Het development team neemt alvast de user stories en designs door en noteert vragen en opmerkingen.
Na de Product Backlog Refinement
Na de Product Backlog Refinement vindt de Sprint Planning plaats. Dit is het eerste Scrum-event van de Sprint. Tussen de Refinement en Sprint Planning heeft de PO nog enkele dagen om zaken intern te verifiëren en/of de prioritering aan te passen.
Meer weten over Scrum?
Wil je meer weten over Scrum en de samenhang tussen de verschillende Scrum-events? We organiseren regelmatig een gratis Scrum webinar waarin we je in één uur meenemen in de werking van Scrum en hoe we Scrum bij Netvlies toepassen.
Meld je gratis aan
Begrippenlijst
User story
Een specifieke wens, op basis van een afgekaderde functionaliteit.
Product Backlog
De verzameling van alle wensen die in het product kunnen komen. Deze wensen (user stories) hebben een unieke prioriteit op basis waarvan ze tijdens de sprint worden opgepakt.
Sprint
Een iteratie van 2 of 3 weken, waarin een multidisciplinair team een set van wensen (user stories) oppakt.
Product Owner (PO)
De afgevaardigde van de klant die bij het team op kantoor zit. De PO kan ter plekke knopen doorhakken en vragen beantwoorden en houdt zo de vaart erin. Het is daarom belangrijk dat de PO hiervoor van zijn of haar organisatie voldoende tijd en mandaat krijgt.
Scrum Master
De Scrum Master dient de PO en het (ontwikkel)team. Hij coacht, faciliteert, motiveert en verwijdert belemmeringen in het project en/of voor het (ontwikkel)team. Daarnaast is de Scrum Master ervoor verantwoordelijk dat Scrum wordt begrepen en goed wordt toegepast.
Sprint Planning
Scrum-event waarmee elke sprint begint. Tijdens de Sprint Planning bespreekt het scrumteam welke wensen worden opgepakt, hoe die gerealiseerd worden en hoe complex het realiseren van elke wens is.