Hoe lang hoort een Sprint Review te duren?

Soms sluit ik wel eens aan bij de Sprint Reviews van collega-teams. Dat heeft twee redenen. De eerste is om op de hoogte te blijven van waar mijn collega’s mee bezig zijn. De tweede reden is in de hoop iets op te steken van hoe wij onze eigen Reviews opzetten.

Wat opvalt, is dat er een behoorlijke diversiteit in tijdsduur is tussen de Reviews van de verschillende teams. De onze zijn getimeboxt op een uur en ‘n kwartier, al duren ze in de praktijk meestal ongeveer een uur. Maar ik woon ook Reviews bij van een halfuurtje.

Efficiënter

Wat is er aan de hand? Leveren we twee keer zoveel functionaliteit op als die teams? Werken we gewoon harder of efficiënter?

Ik zou graag willen zeggen van wel, maar dat is natuurlijk niet waar. Het zou ook opvallend zijn, want de teams bij wiens Sprint Reviews ik aansluit zijn niet zelden groter dan het mijne.

Je kunt als team de tijd nemen voor één onderwerp, of twaalf features er in een kwartier doorheen rammen. Het aantal opgeleverde features is niet één op één gerelateerd aan de tijd die je ervoor uittrekt om ze te presenteren.

Wijdlopig

Maar wat dan? Leveren we, kwantitatief bezien, ongeveer dezelfde output en zijn we alleen wat wijdlopiger in onze presentatie?

Dat zou een deel van de oplossing kunnen zijn. Wat me opvalt is dat mijn team bijvoorbeeld redelijk wat tijd uittrekt om stakeholders uit te leggen waarom we aan zaken hebben gewerkt die gerelateerd zijn aan productkwaliteit, zoals het opruimen van technische schuld of het aanpassen van de architectuur om toekomstige wijzigingen mogelijk te maken.

Zulke wijzigingen leveren geen waarde in enge zin voor de stakeholders - ze leveren geen nieuwe functionaliteit op - en worden volgens mij daarom vaak overgeslagen door andere teams. De stakeholders zijn niet intrinsiek geïnteresseerd in softwarearchitectuur, zo is de redenering, en daarom kunnen we hen er maar beter niet mee lastigvallen.

Empathie

Eerlijk is eerlijk, soms geven onze stakeholders ook aan zich maar matig te interesseren voor dit soort codewijzigingen. Toch ben ik van mening dat het belangrijk is om hen daarover te informeren.

Ten eerste hebben ze het recht om te weten waar het team zijn tijd - en hun geld! - aan besteedt. Ten tweede is het een middel om empathie te kweken. De stakeholders moeten weten dat we hard in de weer zijn om hun wensen te realiseren, ook wanneer dit niet onmiddellijk wordt verzilverd in een nieuwe feature.

Eenrichtingsverkeer

Toch is dat niet de enige reden waarom onze Sprint Reviews ruim twee keer zolang duren dan die van andere teams. De belangrijkste reden waarom we de tijd nemen voor deze sessies, is om stakeholders de gelegenheid te geven om zich uit te spreken over de waarde die het team geleverd heeft.

Dat is wat mij het meest opvalt aan Sprint Reviews die een halfuur duren: ze zijn een schoolvoorbeeld van éénrichtingsverkeer. Een halfuur is een redelijk krappe timebox, en het team heeft vaak maar net de ruimte om alle opgeleverde functionaliteit toe te lichten en te demo’en.

Die tijdsdruk voelen stakeholders ook, en daarom trekken ze alleen hun mond open wanneer ze dringende vragen hebben. Het merendeel neemt het verhaal van het team ter kennisgeving aan en verlaat de Review zonder één woord gezegd te hebben.

Feedback

De halfuur durende Sprint Review verloochent daarmee de belangrijkste functie van een Sprint Review: feedback krijgen van je stakeholders. Je wil als team altijd weten wat je stakeholders vinden van de opgeleverde functionaliteit. En dan vooral: waar ze nog ruimte zien voor verbetering, of zelfs ruimte eisen voor verbetering.

Ik denk dat onze Reviews voor zo’n 70 procent bestaan uit het presenteren van de features, en zo’n 30 procent uit het uitvragen van de stakeholders naar hun mening. Ik zal niet liegen: mondige stakeholders kunnen behoorlijke lastpakken zijn. Maar aan het eind van de dag mag je je in je handen wrijven met een kritisch klankbord, daar heb je veel meer aan dan jaknikkers - of ze de ruimte hebben gekregen om hun mening te geven of niet.

Kwartier

Betekent dat dat een Sprint Review van een halfuur altijd te kort is, en een uur altijd lang genoeg? Absoluut niet.

Mijn leidinggevende vertelde me laatst dat hij bij zijn vorige werkgever, in de rol van PO, te maken had met stakeholders die wel twintig of dertig Sprint Reviews op een dag hadden. Laat het gezegd zijn: die stakeholders hadden geen behoefte aan Reviews van een uur!

De Sprint Reviews van mijn leidinggevende werden daarom gecomprimeerd tot een kwartier. Is dat werkbaar, gegeven wat ik hierboven uiteenzette over stakeholders die dichtslaan in Reviews van een halfuur? Ja, want de stakeholders van mijn leidinggevende waren ontzettend mondig, en er bovendien op ingesteld om op basis van weing informatie snel een mening te vormen.

Hoe lang?

Regelmatige lezers van deze blog zullen het antwoord op de vraag in de titel waarchijnlijk wel al kunnen raden: it depends. De eigenlijke vraag is: wáár hangt het vanaf?

Het antwoord op die vraag is: van de behoeften van de stakeholders.

Een Sprint Review hoort niet een uur of een halfuur of een kwartier te duren. Een Sprint Review duurt zo lang als dat stakeholders nodig hebben om feedback te kunnen leveren op het in die Sprint opgeleverde increment.

communicatie · empathie · scrum · sprint review · stakeholders