# Sprint Reviews in high performance Scrum > Ik leerde over Scrum lang voordat de manifest-update van 2020 er was. Toen we na die release van 2020 een Scrum Master-training volgden, hadden we een leuke discussie over de verandering die sinds de update van de Scrum Guide de meeste impact op mij heeft gehad. - URL: https://www.allsubjectsmatter.nl/nl/sprint-reviews-in-scrum/ - Language: nl - Published: 2023-08-29 - Updated: 2024-02-16 - Author: Remco Loup (https://www.allsubjectsmatter.nl/nl/author/remco/) - Tags: Agile - Original (en, written by the author): https://www.allsubjectsmatter.nl/sprint-reviews-in-scrum/ - Note: this text was translated with AI from the original. ## Inleiding Ik leerde over Scrum lang voordat de manifest-update van 2020 er was. Toen we na die release van 2020 een Scrum Master-training volgden, hadden we een leuke discussie over de verandering die sinds de update van de Scrum Guide de meeste impact op mij heeft gehad. De verschuiving van één inspecteerbaar werkend artifact aan het einde van een sprint, naar veel vaker releasen binnen de sprint zelf. Dat is een goede ontwikkeling, want we leven in een CI/CD-wereld en iets vasthouden als het Done is, is niet nodig. Mijn probleem ermee is dat het de focus weghaalde bij wat ik wist over wat een Sprint Review was. En dat zette me aan het denken. ## Wat meer achtergrond Voor ons team betekent de status "Done" dat een feature klaar is voor deployment. Dat wil niet zeggen dat we overhaast releasen; ingrijpende wijzigingen worden zorgvuldig afgewogen, zodat ze aansluiten bij de wensen van gebruikers en bredere doelen. Elke update wordt grondig gecontroleerd, waarbij onze Product Owner een sleutelrol speelt en de release afstemt op de zakelijke belangen. Met een goede CI/CD-implementatie kan je team vergeten dat een update al is gereleased zodra die in onze staging-omgeving staat. Wanneer we de trekker overhalen en live gaan, is aan de business. Het team moet wel weten wanneer iets volledig is gereleased, want we houden mogelijke problemen ook in de gaten. Maar de Developers zouden geen belang bij de daadwerkelijke release moeten hebben. Ik snap dat dit wat meer uitleg verdient. Dat bewaren we voor een toekomstige post. In onze DONE-lane houden we DONE-nog-niet-gereleased en DONE-gereleased apart. ## Onze mini-Sprint Reviews Om het scherp te formuleren: onze feature-releases lijken vaak op een reeks "mini-Sprint Reviews" > Er is een uitgebreide discussie over wijzigingen en mogelijke gevolgen. > Deployment-momenten worden strategisch gepland. > Gedetailleerde changelogs worden samengesteld. > Stakeholders worden op de hoogte gehouden en hun feedback wordt na de release actief opgevraagd. > Door deze grondige aanpak zijn de grote gesprekspunten vaak al behandeld tegen de tijd dat onze Sprint Review eraan komt. Dat haalt een aantal onderwerpen weg uit de Sprint Review. Zeker als je een goede CI/CD-pipeline hebt en vaak releaset. Als je updates vóór het einde van de sprint bespreekt en live zet, en je de feedback op de gereleasde features al binnenkrijgt — waarom zou je mensen dan nog een keer om feedback of een discussie over die release vragen? Scrum is een framework dat gesprekken mogelijk maakt. Maar er moet wel waarde in die meetings zitten. En voor ons is de Sprint Review over dit onderwerp behoorlijk nutteloos geworden. ## Wat bespreken we dan? Je zou je kunnen afvragen: met zo'n grondige evaluatie vóór de release, wat blijft er dan over voor de Sprint Review? We zijn onze aanpak nog aan het verfijnen, maar dit is onze huidige structuur > Toetsen of we het sprintdoel hebben gehaald. > Analyseren welke taken in de sprint onaangeroerd zijn gebleven. > Dieper ingaan op lopende development-items. > Het backlog bijstellen naar aanleiding van veranderingen uit de afgelopen sprint, zodat komende sprints duidelijke prioriteiten hebben. > Proactief nieuwe taken of aanpassingen identificeren op basis van recente lessen. > Stakeholders betrekken voor gedetailleerde feedback waar dat nodig is. Zo werken biedt ons een paar duidelijke voordelen. Onze stakeholders zitten in alle afdelingen van ons bedrijf. Veel van hen werken hybride of zelfs 3/4 dagen in een hybride combinatie. Door frequent te releasen en ons plannen daarop aan te passen, bespreken we de release op een moment dat ze op kantoor zijn, en dat werkt voor ons gewoon het beste. De mogelijkheid om dingen face to face te bespreken is van onschatbare waarde. Het werkt gewoon beter en zorgt voor meer begrip tussen elkaar. Onze reviews vallen traditioneel op vrijdag. Dat is geen probleem, want we kunnen de stakeholder gewoon op elke dag dat we klaar zijn een seintje geven. De update bespreken. En live gaan. We hoeven hier niet zo'n drama van te maken. We hebben korte feedbackloops! Vreselijke meetings inplannen is iets voor trage, grote bedrijven waar iedereen denkt dat hij belangrijk is en alles vastloopt in bureaucratie. In de meeste van onze Sprint Reviews bespreken we niets over wat we hebben gedeployd. We inspecteren de increment niet. De increment is al geïnspecteerd en we gaan snel door naar de andere onderwerpen die hierboven staan. ## Conclusie Een paar essentiële elementen sturen deze aanpak van ons aan. Een Product Owner met echte beslissingsbevoegdheid, die de afstemming op bredere zakelijke doelen garandeert. Je hebt een Scrum-team nodig dat strak samenwerkt om volledige stories of features af te ronden. Ze écht DONE krijgt. Je hebt FLOW in je team nodig om dit voor elkaar te krijgen. Je hebt een goede CI/CD-omgeving nodig waarin je geautomatiseerd en vaak kunt deployen. (Daar werken we zelf nog aan. We zijn geautomatiseerd, maar nog niet genoeg. Er kan nog veel meer handwerk uit.) Scrum blijft zich ontwikkelen, en onze werkwijze ook — altijd met waarde en efficiëntie voorop.