Stel je voor, je wilt een boek laten schrijven over iets belangrijks dat je hebt meegemaakt. Je zoekt een ghostwriter en voert veel gesprekken met haar. Je vertelt haar uitvoerig wat je hebt meegemaakt, zodat ze een goed beeld krijgt van wat er wel en wat niet in het boek moet komen te staan.
Zodra de schrijfster voldoende informatie heeft, gaat ze aan de slag. Na anderhalf jaar is het boek klaar en krijg je het allereerste exemplaar toegestuurd. Je begint verwachtingsvol te lezen, maar ontdekt al snel dat er veel onwaarheden in staan. Het gevolg is dat grote delen van het boek herschreven moeten worden.
Controle houden
Mocht jij echt een boek laten schrijven, zou je de schrijfster dan niet liever regelmatig willen spreken? Zou je de nieuw geschreven tekst niet elke twee weken willen lezen, zodat je de tekst indien nodig kunt bijsturen? En zo controle houden op de inhoud van het boek?
Dat is precies de reden waarom Scrum aan het einde van elke sprint een sprintreview heeft. Die is bedoeld voor de business om controle te houden over de ontwikkeling van het product.
De sprintreview is niet simpelweg een demo of een presentatie van de ontwikkelde software.
Het is een bijeenkomst waarin het scrum team en de stakeholders samenwerken aan het verbeteren van de oplossing. Er is veel onderlinge interactie. Het scrum team laat weliswaar zien waar ze de afgelopen sprint aan hebben gewerkt, maar dat is slechts als aanzet voor de gedachtewisseling die daarna volgt.
Requirements
De mening en actieve betrokkenheid van stakeholders tijdens de sprintreview zijn erg belangrijk. Het helpt het scrum team (inclusief de product owner en analist) om de requirements beter te begrijpen en de user stories voor de komende sprints te selecteren.
De aanvullende informatie die ze tijdens de sprintreviews krijgen, zorgt ervoor dat het team betere beslissingen kan nemen. Het gaat dan bijvoorbeeld over extra informatie over het bedrijf, de context, achtergronden, problemen, methode, behoeften, enz.
Het is altijd fijn te horen als stakeholders blij zijn met de ontwikkelde software, maar vooral wanneer dat niet het geval is, is dat belangrijk om te weten. Nieuwe requirements en kritiek van stakeholders kun je zien als kansen om meer businesswaarde te creëren.
Het beste resultaat
Sprintreviews zijn voor stakeholders de uitgelezen momenten om van zich te laten horen. Ze mogen kritisch zijn op de ontwikkelde software en ook op de gestelde prioriteiten en volgorde van de user stories op de product backlog.
Voor het scrum team bieden de sprintreviews de kans om een constructief gesprek met de business aan te gaan en afspraken te maken, zonder dat daarvoor afzonderlijke bijeenkomsten georganiseerd hoeven worden.
Zo bereik je samen het beste resultaat voor de organisatie. De business geeft aan waar de kansen, problemen en behoeften liggen en het scrum team doet haar best om de best passende oplossing te realiseren.
Vertrekpunt
In veel organisaties laat de samenwerking tussen de business en het scrum team nog te wensen over. Als analist ben je dikwijls in de positie om beide partijen dichter bij elkaar te brengen. Daar is wel een lange adem voor nodig, want het gaat in kleine stapjes.
De sprintreview is dikwijls een goed vertrekpunt. Moedig stakeholders aan om naar de sprintreview te komen en hun stem te laten horen. En moedig het Scrum team aan om informatie en feedback van de stakeholders te vragen.
Dan wordt de sprintreview een instrument om de requirements helder te krijgen in plaats van enkel een saaie demo.
Hoe heeft jouw team de sprintreview vorm gegeven? Ben je daar tevreden over of juist niet? Ook je tips of vragen zijn welkom. Ik lees je reactie op dit artikel graag hieronder in de reactie-sectie.
Michel van der Meulen
Dit artikel is oorspronkelijk in het Engels gepubliceerd op michelvandermeulen.com. Dit is een vertaalde en bewerkte versie.
