Marco Balvers

De sprint review is één van de standaard onderdelen van een SCRUM project die bij elke sprint opnieuw wordt uitgevoerd. Het is dan ook de moeite waard om het optimale resultaat te halen uit deze review.

We zien in onze dagelijkse praktijk vaak dat de sprint review wordt beschouwd als een formele afsluiting van de sprint. De product owner keurt de stories goed en het SCRUM team is blij met de goede afloop van de sprint.

Stakeholders zijn meestal niet uitgenodigd of haken na enkele sprints af, veelal doordat de demo te technisch is of doordat de demo wordt gegeven met onjuiste of niet representatieve testdata.

Het doel van een sprint review is echter juist om feedback van stakeholders te verkrijgen. Daarom is het belangrijk om na te denken welke vorm en werkwijze voor het project het beste resultaat oplevert. Een goede voorbereiding van de sprint review is daarbij van essentieel belang.

In dit artikel geven we enkele tips voor productieve sprint reviews en delen we ervaringen uit onze dagelijkse praktijk.

Doel van de sprint review

Tijdens een sprint review inspecteren we de afgelopen sprint en verzamelen we feedback van de stakeholders. De belangrijkste aandachtspunten tijdens een sprint review zijn:

• Tonen wat er bereikt is (live demo);
• Verzamelen van feedback;
• Bevorderen van onderlinge samenwerking;
• Indien nodig aanpassen van de backlog.

Sprint review zijn veelal informeel van aard om de feedback en samenwerking te bevorderen. Dit is niet het moment voor de product owner om stories goed te keuren. Stories die tijdens de sprint review aan bod komen zijn vooraf immers al aan de product owner gepresenteerd.

De juiste mensen

Om zinvolle feedback te kunnen verzamelen is het belangrijk dat de juiste mensen bij de sprint review aanwezig zijn. Bepaal daarom welke stakeholders feedback kunnen geven en nodig ze tijdig uit. Denk daarbij aan:

• Product owner;
• Senior users/ambassadeurs;
• Business verantwoordelijken;
• Scrum team;
• Operatie (indien niet vertegenwoordigd in het scrum team);
• Implementatie.

Wijs een verantwoordelijke aan voor de uitnodiging en het actief monitoren van de opkomst. Als een belangrijke stakeholder meerdere keren niet aanwezig is, zoek dan persoonlijk contact en probeer belemmeringen weg te nemen.

Mogelijk is de dag of het tijdstip niet gunstig. Of misschien is de demo een keer inhoudelijk niet interessant geweest. Meld vooraf wanneer een demo mogelijk minder belangrijk is voor een genodigde. Dan kan de genodigde nog altijd kiezen of hij of zij aanwezig zal zijn.

Goede voorbereiding

Een goede sprint review vereist ook een gedegen voorbereiding. Als pas enkele uren van tevoren over de sprint review wordt nagedacht dan zal deze niet optimaal zijn. Door op tijd over de review na te denken zal de kwaliteit verbeteren. Hierbij stellen we de volgende richtlijnen voor:

• Reserveer aan het begin van de sprint daadwerkelijk tijd voor de voorbereiding. Maak hiervoor bijvoorbeeld een algemene taak aan op het scrumboard voor iedere sprint. Of maak per story die je in de review wil laten laten zien een “review” taak.
• Start met de voorbereiding als duidelijk wordt dat een story daadwerkelijk zal worden opgeleverd in de sprint, niet de dag voor de review.
• Bespreek met de betrokken teamleden de scenario’s die in de review worden getoond.
• Verzamel tijdig aansprekende en life-like (test) data.
• Stel de product owner tijdig op de hoogte (stories goedgekeurd).
• Stel omgevingen veilig voor het tijdslot van de review.

Schets altijd de context van een story

In een sprint review ligt de nadruk terecht vaak grotendeels of uitsluitend op een live demo van software. Stakeholders waarvan feedback wordt verwacht zijn echter niet altijd bij de sprint betrokken geweest en kunnen geholpen worden met een korte situatieschets of inleiding van de story.

Schets daarom per story altijd de context zodat de stakeholder weet waar hij feedback op moet geven en wat er nog gaat komen en dus geen onderwerp van discussie is.

• Beschrijf de feature/epic waar de story bij hoort als context.
• Beschrijf de actuele status van de feature/epic. Benoem stories die al zijn afgerond en die nog op de backlog staan om onnodige discussie te voorkomen.
• Beschrijf business doel en resultaten van de story in business termen.
• Markeer de plaats in de presentatie waar de live-demo gaat komen, bijvoorbeeld met een vast symbool.

Deze schets/inleiding is vaak goed vorm te geven met behulp van allerlei presentatietechnieken. Dit kan een powerpoint presentatie zijn maar filmpjes of andere presentatievormen zijn uiteraard ook mogelijk. Enkele algemene aandachtspunten voor de presentatie:

• Gebruik de taal van de stakeholders.
• Gebruik de juiste huisstijl van de organisatie.
• Besteed tijd en aandacht aan details.
• Zorg voor een goede verhouding tussen tekst en plaatjes.
• Gebruik herkenbare plaatjes en symbolen in de context van het bedrijf.

De presentatie kan ook worden gebruikt om afwezigen achteraf te informeren. Zorg in dat geval voor voldoende tekst en voeg enkele screenshots van de live demo toe.

De uitvoering

Begin de sprint review met een korte intro, bijvoorbeeld een korte agenda in de presentatie. Vertel kort over problemen die het team heeft overwonnen en belangrijke gebeurtenissen als releases.

Behandel daarna de diverse stories:

• Vertel zoals hiervoor beschreven eerst de context van de story. De spreker (vaak een analist) moet de stakeholders kennen, hun taal spreken en eventuele vragen kunnen beantwoorden.
• Toon vervolgens indien mogelijk een live demo. De bediening en toelichting wordt gegeven door iemand die handig is met de knoppen en weet hoe hij testdata beschikbaar kan maken. Dit is vaak een developer of tester.
• Zorg voor een vloeiende overgang tussen presentatie en live demo, bijvoorbeeld door een monitor met twee ingangen.
• Maak vooraf afspraken over wie feedback noteert. Dit is bij voorkeur de product owner.

Na afloop wordt de feedback door de product owner en het SCRUM team besproken. De product backlog wordt zo nodig aangepast, aangevuld of opnieuw geprioriteerd.

Hoe denkt u hierover?

Goede sprint reviews vragen voorbereiding en tijd. Dit kan zich echter snel terugbetalen doordat stakeholders beter betrokken worden, ze daardoor vaker bij de sprint review aanwezig zijn, doordat ze gerichte feedback geven en doordat de kwaliteit van de backlog verbetert. Al deze zaken kunnen bijdragen aan het succes van het project.

De tips voor de voorbereiding en uitvoering van sprint reviews in dit artikel zijn gebaseerd op onze eigen ervaring binnen diverse SCRUM projecten. Kunt u zich vinden in onze aanpak? Waarom wel of waarom niet? Ik verneem uw mening of vragen graag via het reactieformulier onderaan deze pagina, via info@divetro.nl of +31 (0) 88 000 54 00.

Meer lezen?

Wilt u meer tips over Agile en/of analyse? Lees hier onze overige publicaties en schrijf u vrijblijvend in voor onze nieuwsbrief. U ontvangt onze publicaties dan automatisch wanneer ze op onze website verschijnen.

Schrijf u in