De vorige blogs gingen over de pitfalls bij de Product Backlog, de Sprint Planning, de Daily Scrum en de Sprint. Vandaag gaan we verder met de pitfalls tijdens de Sprint Review.

Pitfalls tijdens de Sprint Review 

“Scrum (zn.): Een raamwerk waarbinnen mensen complexe, adaptieve problemen aanpakken en tegelijkertijd op een productieve en creatieve wijze producten opleveren met de hoogst mogelijke waarde.” 

Complexe problemen zijn problemen waarvan we vooraf niet weten wat de oplossing is en hoe we daar komen. We weten ook niet wat het effect van een bepaalde actie of stap richting de oplossing gaat zijn. David Snowden omschrijft het complexe probleemdomein in het Cynefin Framework. Deze problemen kunnen het best opgelost worden met een ‘Probe – Sense – Respond’ aanpak: we proberen iets waarvan we denken dat het ons dichter bij de oplossing brengt; we nemen waar wat de effecten zijn; en reageren hierop. De Sprint Review is hier essentieel voor.  

“Een Sprint Review wordt gehouden […] om het Increment te inspecteren en indien nodig de Product Backlog aan te passen. Gedurende de Sprint Review bekijken het Scrum Team en de belanghebbenden samen wat er bereikt is gedurende de Sprint. Op basis hiervan en op basis van veranderingen in de Product Backlog, werken de aanwezigen samen aan de volgende stappen die genomen kunnen worden om waarde te optimaliseren.” 

Het Cynefin Framework dit is uitgebreider besproken in onze blog Back to Basics. 

1. Als Scrum Master de uitnodiging van de Sprint Review versturen

De aanwezigen van de Sprint Review worden uitgenodigd door de Product Owner. Zij is de enige die weet welke belanghebbenden moeten worden uitgenodigd voor de door het Ontwikkelteam gerealiseerde functionaliteit. Als Scrum Master zorg je ervoor dat de Sprint Review plaatsvindt. Dat is niet hetzelfde als de uitnodigingen sturen. De Sprint Review is een belangrijke feedbackloop voor het product, het is dus logisch dat het eigenaarschap van het event bij de eigenaar van het product ligt: de Product Owner. Door als Scrum Master de uitnodiging voor de Sprint Review te sturen loop je het risico dat je niet de juiste belanghebbenden uitnodigt. Tevens ontneem je de Product Owner een kans om eigenaarschap te tonen. 

2. Als Scrum Master de Sprint Review voorzitten 

De huidige staat van het product staat centraal in de Sprint Review. Het is aan de eigenaar van het product om de belanghebbenden van het product te verwelkomen en het event voor te zitten. Als Scrum Master ben je ervoor verantwoordelijk dat: 

1. De Sprint Review plaatsvindt; 
2. Alle aanwezigen het doel begrijpen; 
3. De betrokkenen de Sprint Review binnen de timebox houden; 
4. Het resultaat van de Sprint Review (een herziene Product Backlog welke de waarschijnlijke Product Backlog items voor de volgende Sprint definieert) wordt behaald. 

Zolang dit het geval is kun je als Scrum Master in principe achteroverleunen en observeren. 

3. De Sprint Review is niets meer dan een Demo 

De demonstratie van het product is een belangrijk onderdeel van de Sprint Review, en kun je zien als ‘Sense’ binnen ‘Probe – Sense – Respond’. De Sprint is ‘Probe’. ‘Respond’ vindt deels* plaats tijdens de Sprint Review:  

“Op basis hiervan (wat er bereikt is gedurende de Sprint) en op basis van veranderingen in de Product Backlog, werken de aanwezigen samen aan de volgende stappen die genomen kunnen worden om waarde te optimaliseren.” 

 
De Sprint Review bestaat uit meer onderdelen dan alleen de Demo, die er gezamenlijk voor zorgen voor het behalen van het resultaat van de Sprint Review: een herziene Product Backlog welke de waarschijnlijke Product Backlog items voor de volgende Sprint definieert. Het is als Scrum Master aan jou om ervoor te zorgen dat dit resultaat (binnen de timebox) wordt behaald, dat is onmogelijk als de Sprint Review enkel uit een Demo bestaat. 
 
*De Sprint Planning speelt ook een rol voor ‘Respond’. 
 

4. Een Sprint Review zonder belanghebbenden* 

Bij beginnende Scrum Teams zien we met enige regelmaat dat het Ontwikkelteam het product Increment tijdens de Sprint Review demonstreert aan de Product Owner zonder dat hier belanghebbenden buiten het Scrum Team bij zijn. Vaak is dit ook nog eens de eerste keer is dat de Product Owner het nieuwe product Increment ziet.  

De Sprint Review is een belangrijk moment om te toetsen of de behoeften van belanghebbenden op de juiste manier zijn vertaald naar een product Increment. Zonder deze belanghebbenden gaat hier geen goede feedback op komen. De feedbackloop niet gesloten, je mist de ‘Sense’ uit ‘Probe – Sense – Respond’. Het is ook niet goed mogelijk te bepalen wat de volgende stappen zijn die genomen kunnen worden om de waarde te optimaliseren: ‘Respond’ uit ‘Probe – Sense – Respond’. 

De Product Owner is verantwoordelijk voor het optimaliseren van de waarde van het werk dat het Ontwikkelteam uitvoert. Dit is een onderdeel van Product Backlog management. Als Scrum Master dien je de Product Owner op een aantal manieren, waaronder het vinden van technieken voor een effectief Product Backlog management. Als de Product Owner geen belanghebbenden uitnodigt voor de Sprint Review is er voor jou als Scrum Master dus werk aan de winkel. 
 
* Gebruikers zijn belanghebbenden. Als het interne gebruikers zijn (zoals bij mijn huidige coachingsopdracht), dan is het zeker nuttig hen uit te nodigen voor de Sprint Review. 
 

5. Na de Sprint Review wordt het nieuwe product Increment vrijwel nooit in productie genomen 

Feedback tijdens de Sprint Review is belangrijk, maar de beste feedback krijg je van gebruikers als ze het product Increment daadwerkelijk in de praktijk gaan gebruiken. Voor de beste feedback moet het product Increment dus regelmatig in productie worden genomen. 

Dat dit vaak mis gaat heb ik jaren geleden bij mijn vorige werkgever gemerkt bij een opdracht voor een telecombedrijf. Ik werd onderdeel van een Ontwikkelteam dat al een jaar aan een app werkte. Op mijn eerste werkdag kreeg ik de app op mijn telefoon, dat zag er goed uit dus ik vroeg hoeveel gebruikers er waren. Mijn collega’s keken me aan alsof ze water zagen branden. De app was nog niet perfect, dus stond nog zeker niet live! Een jaar later eindigde mijn opdracht en waren we net in productie. Een jaar later is de stekker eruit getrokken: er bleek geen markt voor de app. Ik denk niet dat de managers daar onderstaande video van Eric Ries over het concept ‘Minimal Viable Product’ kenden. 

Het is overigens aan de Product Owner om te bepalen wel of niet te releasen: 

“Ontwikkelteams leveren elke Sprint een Increment van product functionaliteit. Dit increment is bruikbaar, zodat een Product Owner kan besluiten dit onmiddellijk te releasen/vrij te geven.” 

De volgende keer gaan we verder met SM pitfalls bij de Sprint Retrospective. 

Heb je nu vragen over, of wil je doorpraten over een van bovenstaande pitfalls?  
Laat dan een berichtje achter onder de LinkedIn post van deze blog, of bel 030 - 20 20 833. 

Stefan Kennedie

Stefan is een enthousiaste Scrum en Agile consultant en trainer die veel ervaring heeft in het trainen en coachen van professionals voor wie Agile en Scrum nieuw zijn. Hij heeft uitgebreide ervaring in het toepassen van Scrum bij organisaties buiten het IT-domein.