Sprint Review: Hoe verloopt een Review in Scrum & Agile?

De meest voor de hand liggende activiteit in een Sprint Review Meeting is de demonstratie van functionaliteit die in de voorgaande Sprint is gebouwd. Een goede Sprint Review is echter meer dan alleen een demonstratie. Laten we samen eens kijken naar een agenda voor een Review Meeting.

De juiste voorwaarden voor de Review creëren

De Product Owner begint de Sprint Review Meeting door alle deelnemers welkom te heten. Het is al voldoende om zoiets te zeggen als: „Bedankt dat jullie er allemaal zijn."

Als de aanwezigen elkaar niet kennen, kan de Product Owner hen vragen om zich kort voor te stellen. Aan het begin van een nieuw productontwikkelingsinitiatief is een voorstelronde sowieso een goed idee. De Product Owner weet weliswaar dat Joe van Marketing Joe van Marketing is, maar de teamleden weten dat misschien niet.

Daarnaast is het handig dat alle deelnemers zich kort voorstellen wanneer er af en toe nieuwe deelnemers bij de Sprint Reviews aansluiten. Het kan namelijk zijn dat Joe van Marketing alleen aanwezig is bij de Sprint Reviews van de twee Sprints waarin het team aan marketinggerelateerde features heeft gewerkt.

Het voorstellen moet echt kort en bondig gehouden worden. „Hoi, ik ben Mike en ik ben developer. Ik heb aan de winkelwagen-features gewerkt" is eigenlijk al bijna te veel. „Hoi, ik ben Mike en ik ben developer" zou in de meeste gevallen al voldoende zijn. Zodra een team echter een bepaalde grootte bereikt, kan het voor de stakeholders best nuttig zijn om kort te horen waar iedereen aan heeft gewerkt.

Na de begroeting en de eventueel benodigde voorstelronde aan het begin kan de Product Owner nog een aantal regels opstellen of de verwachtingen voor de Sprint Review benoemen. Sommige Product Owners vinden het bijvoorbeeld belangrijk om erop te wijzen dat je ook tijdens de Sprint Review altijd vriendelijk moet blijven. Als iemand het niet eens is met hoe een feature is geïmplementeerd, mag dat natuurlijk gezegd worden, maar noem de implementatie dan niet „belachelijk". Ja, natuurlijk weten we dit allemaal wel, maar soms moet je er even aan herinnerd worden.

Afhankelijk van het aantal deelnemers en vele andere factoren kan de Product Owner de aanwezigen ook uitleggen dat er in de Review weliswaar om feedback op de tot nu toe gebouwde features wordt gevraagd, maar dat dit niet het moment is om features helemaal opnieuw te ontwerpen.

Zodra je klaar bent met de intro en de regels voor de Review, is het tijd om naar het volgende punt op de agenda te gaan.

Wat wordt er in een Review gedemonstreerd - en wat niet?

Op dit punt beginnen veel teams direct met de demonstratie. Ik raad aan dat de Product Owner eerst een kort overzicht geeft van wat er gedemonstreerd gaat worden en wat niet.

Om te voorkomen dat de Product Owner slechts een lijst met items voorleest waar de deelnemers niet in mee kunnen komen, moet dit voor iedereen zichtbaar worden getoond op een monitor of projector. Of je print de lijst vooraf uit voor degenen die er eventueel een kopie van willen hebben.

Persoonlijk stuur ik deze informatie graag de avond voor de meeting als Word-document in een e-mail naar alle potentiële deelnemers van het Sprint Review Meeting. Dit geeft mensen de kans om vooraf al te zien wat er gedemonstreerd gaat worden. Op basis daarvan kan iedereen voor zichzelf beslissen of het de moeite waard is om deel te nemen aan de Sprint Review.

De volgende tabel toont de informatie die naar mijn mening voor elk Product Backlog Item relevant is. Ik zou voorstellen om de items op te lijsten in de volgorde waarin ze ook gedemonstreerd worden. Dit kun je echter naar behoefte ook nog spontaan aanpassen.

Het eerste punt in de tabel is een beschrijving van het betreffende item. Daar wordt een User Story of een andere beschrijving ingevoegd. Vervolgens komt de grootte van de items – meestal in Story Points. Daarna komt de status van de items. Hoofdzakelijk gaat het erom of ze afgerond zijn of niet. Maar alles wat in dat opzicht belangrijk lijkt, kan daar ook worden toegevoegd. De laatste kolom geeft aan of het betreffende item wel of niet gedemonstreerd zal worden.

Je vraagt je misschien af waarom er überhaupt items op de lijst zouden moeten staan die helemaal niet gedemonstreerd hoeven te worden. In de bovenstaande tabel heb ik een aantal voorbeelden opgenomen. Het is vrij duidelijk dat het item dat wel in de Sprint was opgenomen maar vervolgens weer is geschrapt, niet gedemonstreerd kan worden. Daarnaast heb ik een Bug-Fix vermeld waarbij het alleen gaat om een update van een teken op een scherm – ook dit item is niet bedoeld voor de demonstratie.

Het is goed mogelijk dat een of meer deelnemers naar een item vragen dat eigenlijk niet voor de demo was voorzien. Mocht dat gebeuren, dan kun je dit item gerust samen met de andere items presenteren. Het gaat er niet om te voorkomen dat bepaalde items worden getoond, maar om respectvol om te gaan met de tijd van de aanwezigen door hen geen items te laten zien waar je geen feedback op nodig hebt.

In de voorbeeldtabel heb ik een Product Backlog Item opgenomen dat gedurende de Sprint is toegevoegd. Ik vind het zinvol om te kunnen zien welke items vanaf het begin voor de Sprint waren ingepland en welke er tijdens de Sprint bij zijn gekomen. Als het vaker voorkomt dat er items gedurende de Sprint bijkomen, kun je overwegen om een kolom aan de tabel toe te voegen waarin je aangeeft of de items gepland waren of achteraf zijn toegevoegd.

Daarnaast kun je helemaal rechts ook een kolom toevoegen die aangeeft of de items door de deelnemers van het Review Meeting zijn geaccepteerd, klaar zijn voor een Release o.i.d. Dit is vooral zinvol als deze beslissingen een officieel onderdeel van de Sprint Review zijn.

Probeer niet te veel tijd aan dit deel van de agenda te besteden. Het doel hier is niet om feedback op de items te krijgen of te bespreken waarom een gepland item slechts gedeeltelijk is geïmplementeerd. Deze lijst dient alleen om de inhoud van het meeting weer te geven. Nadat de Product Owner deze lijst heeft gepresenteerd, gaan we over naar het belangrijkste onderdeel van de Sprint Review: de demonstratie.

Nieuwe functionaliteiten demonstreren

Dit is het hart van elke Sprint Review Meeting. Als je al Sprint Reviews houdt, is de kans groot dat dit het enige deel van de agenda is dat je daadwerkelijk uitvoert.

In dit deel van de Sprint Review loop je stap voor stap door de lijst met items die je eerder aan de aanwezigen hebt laten zien. Onthoud dat het doel van een Sprint Review Meeting is om feedback te ontvangen.

Er zijn geen vaste regels over wie de demo zou moeten geven. In sommige gevallen neemt de Product Owner dit op zich. Dat zou ik altijd aanraden als er bijzonder lastige stakeholders bij de Review aanwezig zijn. In andere gevallen demonstreren de betreffende teamleden zelf de items waaraan ze hebben gewerkt. Vrijwel elke variant is hier toegestaan. Experimenteer er gewoon een beetje mee en ontdek wat voor jouw team het beste werkt.

De belangrijkste punten bespreken

Wanneer alle afgeronde Product Backlog Items zijn gedemonstreerd, worden de belangrijkste gebeurtenissen of problemen van deze Sprint besproken.

De discussie kan worden gefaciliteerd door de Scrum Master of de Product Owner. Naar mijn ervaring werken beide modellen even goed. Persoonlijk heb ik echter een lichte voorkeur dat de Scrum Master dit deel van de meeting op zich neemt.

Tot dit punt in de Review zal de Product Owner aanzienlijk meer aan het woord zijn geweest dan de Scrum Master. Daarom vind ik het een goede balans als de Scrum Master dit deel van de agenda faciliteert. Bovendien gaat het hier strikt genomen meestal meer om een discussie over het proces dan over het daadwerkelijke product. Daardoor valt het iets meer binnen het werkgebied van de Scrum Master.

De volgende Product Backlog Items presenteren

Het laatste item op de Sprint Review agenda zou een discussie over de volgende werkzaamheden in de Product Backlog moeten zijn. Aangezien het doel van de Sprint Review is om feedback te verzamelen over het werk uit de huidige Sprint, wordt daardoor ook vaak het werk van de volgende Sprints beïnvloed.

Als de stakeholders de look van de nieuwe schermen bijvoorbeeld erg goed vinden, wil de Product Owner misschien snel andere delen van het product aanpassen aan het nieuwe design. Of misschien bevalt de manier waarop de features zijn geïmplementeerd de stakeholder niet zo goed. Dan kan de volgende Sprint worden gebruikt om deze punten op te lossen in plaats van door te gaan met de volgende items (zoals zonder een Sprint Review zou zijn gebeurd).

De Product Owner begint de discussie met de presentatie van de volgende potentiële items uit de Product Backlog. Hij zegt dan misschien iets in de trant van: „Op het scherm zien jullie tien items die ik voor de volgende Sprint had gepland. Echter zou ik graag nog item XY willen toevoegen, dat vandaag is opgekomen. Waarschijnlijk schuif ik het ertussen als item nr. 3."

De Product Owner vraagt de deelnemers vervolgens naar hun mening over deze lijst. Echter zou de Product Owner naar mijn mening geen prioritering tijdens de Sprint Review moeten doen op basis van deze opmerkingen. Daar zijn meerdere redenen voor. De Product Owner heeft misschien wat tijd nodig om na te denken over wat er gezegd is. Of misschien wil de Product Owner inschattingen van het team krijgen over de wijzigingen die tijdens de Review zijn gevraagd, enzovoort. De Product Owner verzamelt dus tijdens de Sprint Review meningen en neemt de uiteindelijke beslissingen in alle rust na de meeting.

De Review afsluiten

Sluit de meeting simpelweg af door iedereen te bedanken voor hun deelname. Overweeg ook of je niet het team als geheel wilt bedanken voor het werk in de afgelopen Sprint, of af en toe een of twee teamleden die bijzonder goed hebben gepresteerd. Herinner vervolgens iedereen eraan wanneer en waar de volgende Sprint Review Meeting zal plaatsvinden.

Na de Sprint Review

Ook al hoort het niet direct bij de agenda van de Sprint Review, toch moet ervoor gezorgd worden dat alle nieuwe Product Backlog Items ook in de tool van het team worden overgenomen of op een post-it worden geschreven en aan het Scrum Board worden gehangen.