Officiële acceptatie van werk in de Sprint Review – Ja of Nee?

Sommige teams gebruiken de Sprint Review als een mogelijkheid om de in deze Sprint afgeronde Product Backlog Items te laten goedkeuren door de Product Owner of de belangrijkste stakeholders.

In principe zou een team de Sprint Review niet moeten gebruiken om het werk door de Product Owner te laten aftekenen. Het team en de Product Owner zouden al tijdens de Sprint zo nauw moeten samenwerken dat het team sowieso weet wat de Product Owner van hun werk vindt.

„Geen verrassingen" is mijn eerste regel voor de Sprint Review

Het is volkomen acceptabel als een Product Owner het werk van het team voor een bepaald Product Backlog Item niet accepteert. Maar het team zou van tevoren al moeten weten dat dit gaat gebeuren.

De teamleden zouden niet een Sprint Review in moeten lopen en grote waardering voor hun werk verwachten, om vervolgens totaal onverwacht klachten te krijgen.

Kan een Sprint Review officieel worden gebruikt voor de acceptatie?

Wanneer een klant een leverancier de opdracht geeft om een product voor hem te ontwikkelen, treedt idealiter iemand binnen het bedrijf van de klant op als Product Owner. In dat geval kan het prima zijn dat features tijdens de Sprint Review worden goedgekeurd. Toch blijf ik erbij dat er geen verrassingen in de Sprint Review zouden moeten zijn.

Ook als de Product Owner van de klant het team tijdens de Sprint feedback geeft, is het mogelijk dat hij met een officiële acceptatie moet wachten totdat de andere stakeholders de kans hebben gehad om zich over het werk uit te spreken.

Een eenvoudig voorbeeld

Een simpel voorbeeld: mijn dochter vroeg me laatst of ze mee mocht op schoolreis. Ik zei dat ik er geen probleem mee had, maar – je raadt het al – we moesten het nog even aan haar moeder vragen. De reden was dat mijn vrouw voor dat moment misschien al andere plannen voor het gezin had gemaakt, waar ik nog niets van wist.

En de acceptatie in een echt project?

Dit is een alledaagse situatie voor Product Owners bij ontwikkelopdrachten. Ook als de Product Owner, die dagelijks met het team samenwerkt, tevreden is met hoe een feature gebouwd is, moet hij of zij zich er soms toch van vergewissen dat de stakeholders die worden vertegenwoordigd, er ook zo over denken. Natuurlijk zou je kunnen beweren dat de Product Owner gewoon naar hen toe kan gaan om het te vragen. Dat kan echter erg onpraktisch zijn en wordt daarom het beste gewoon tijdens de Sprint Review afgehandeld.

Bij zulke ontwikkelopdrachten levert de klant echter niet altijd een Product Owner. Vaak betaalt de klant ervoor dat de contractpartner zich om alles bekommert.

De klant is natuurlijk wel de eigenlijke Product Owner. De klant zal uiteindelijk het ontwikkelwerk accepteren of afwijzen. Hij of zij wil echter niet dagelijks met deze zaken "lastiggevallen" worden. De oplossing is dan typisch dat de aanbieder een Product Owner uit het eigen bedrijf aanstelt.

En in dit geval kunnen er vóór de Sprint Review dus geen Product Backlog Items geaccepteerd of afgenomen worden. De eigenlijke Product Owner (uit het bedrijf van de klant) is niet beschikbaar en betrokken genoeg om vaker iets af te nemen.

Het team kan uiteraard wel een voorlopige goedkeuring van hun eigen Product Owner krijgen tijdens de Sprint. De echte Product Owner uit het bedrijf van de klant kan in de Sprint Review echter uiteindelijk een heel andere beslissing nemen.

Het definitieve antwoord hangt, zoals zo vaak, af van de context van de betreffende situatie. En daarom moet ik zeggen dat ik me er niet zo druk om maak als de officiële afname van werk in de Sprint Review plaatsvindt. Toch blijf ik erbij dat er in de Sprint Review geen verrassingen zouden moeten zijn. Doe wat voor jou het beste werkt. Als de teamleden maar vóór de Review al weten wat hen te wachten staat.

Deze tekst is afkomstig van de blog van Mike Cohn en is door ons naar het Nederlands vertaald.

Velocity-georiënteerde Sprint Planning

=> Voordelen en nadelen van velocity-georiënteerde Sprint Planning

Wanneer moet de volgorde van Items worden gewijzigd?

=> Hier zijn 5 goede redenen waarom je af en toe de volgorde van Items in de Sprint zou moeten aanpassen.