Sprint Review en AI: waarom een demo het gesprek over waarde niet vervangt

Dit is het vierde artikel in de serie over hoe AI de klassieke bijeenkomsten van een cross-functioneel ontwikkelingsteam verandert. In het eerste artikel behandelde ik Backlog Refinement en liet ik zien dat AI de voorbereiding van materiaal versnelt, maar de teamcontrole op betekenis niet vervangt. In het tweede ging het over Sprint Planning: AI stelt een conceptplan op, maar neemt geen teamverplichting op zich. In het derde over Daily Scrum: AI bereidt signalen voor over de voortgang van de sprint, maar doet de synchronisatie niet voor het team. Nu is het logisch om naar de Sprint Review te gaan en de meest verleidelijke fout te behandelen: een levendig gesprek over waarde veranderen in een fraaie AI-demo.

De Sprint Review lijkt de ideale plek voor AI. Aan het einde van de sprint is er al alles waaruit je gemakkelijk een effectvolle presentatie kunt samenstellen: afgesloten taken in Jira, gemergede pull requests, codewijzigingen, nieuwe schermen, bijgewerkte metrieken, supporttickets, gebruikersfeedback. AI kan binnen enkele minuten release notes samenstellen, een demo-scenario schetsen, slides opmaken, berekenen hoeveel er in totaal is gedaan en zelfs een nette samenvatting genereren van wat gebruikers zeggen.

Op het eerste gezicht is dit pure winst. Minder handmatige voorbereiding. Minder "laten we vijf minuten voor de meeting beslissen wat we laten zien". Minder saai opsommen van wat er gedaan is. De presentatie ziet er professioneel uit, release notes zijn samenhangend geschreven, metrieken mooi gevisualiseerd.

Maar hier zit een valkuil, en die is ernstiger dan bij de Daily Scrum.

De Sprint Review bestaat niet om te demonstreren. De taak is om samen met stakeholders het resultaat van de sprint te inspecteren, de voortgang naar het Product Goal te bespreken en de Product Backlog aan te passen. Als AI de Sprint Review verandert in een gepolijste demo, krijgt het team een mooiere presentatie, maar verliest het het belangrijkste: eerlijke feedback, een gezamenlijke beslissing over "wat nu verder" en verantwoordelijkheid voor het product.

"AI kan de routine van de voorbereiding wegnemen, maar de Sprint Review is waardevol niet door de demo, maar door de beslissing wat er in het product moet veranderen."

Waarom is de Sprint Review nodig

In de Scrum Guide 2020 wordt de Sprint Review vrij strikt beschreven. Het is de op één na laatste gebeurtenis van de sprint, timeboxed op maximaal vier uur voor een sprint van een maand. Het doel is het resultaat van de sprint te inspecteren en verdere aanpassingen te bepalen. Het Scrum Team presenteert de resultaten van het werk aan de belangrijkste stakeholders, en de voortgang naar het Product Goal wordt besproken. En apart, bijna polemisch, verduidelijkt de Scrum Guide: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation" — het is een werksessie, en het team moet die niet tot een presentatie beperken.

Dat is de sleutelzin voor dit hele artikel. De Sprint Review is geen acceptatie van werk door de Product Owner, geen rapportage aan het management, geen marketingdemo voor de klant en geen ceremonie van "we zijn goed bezig". Het is het moment waarop het team en de stakeholders samen kijken naar wat er gedaan is en wat er om hen heen is veranderd, en beslissen wat er nu verder moet gebeuren. Het resultaat van de gebeurtenis is geen applaus, maar een bijgestelde Product Backlog.

Als extra oriëntatiepunt is ook de Scrum Guide Expanded v2026.1nuttig, maar juist als companion-bron, niet als nieuwe canonieke versie van de Scrum Guide. Voor dit artikel is die belangrijk als praktisch kader: de Sprint Review gaat over de echte waardestroom naar stakeholders en de gezamenlijke aanpassing van het productplan, niet over een statuspresentatie. In het hoofdstuk over AI beschrijft hij het model als supervised decision-making partner: AI kan transparantie, inspectie en aanpassing versterken, maar vervangt menselijke verantwoordelijkheid niet en schrapt de empirische controle van het proces niet.

Daarom zou ik het doel van de Sprint Review beschrijven via vijf functies:

• inspectie van het echte resultaat van de sprint, niet van het verhaal erover;
• het verzamelen van eerlijke feedback van stakeholders en gebruikers;
• het controleren van de voortgang naar het Product Goal;
• een gezamenlijke beslissing over wat er nu verder moet gebeuren;
• aanpassing van de Product Backlog, niet alleen het tonen van wat gedaan is.

Dit is het kader voor het gesprek over AI. Als een tool het team helpt deze functies beter uit te voeren, is die nuttig. Als die alleen de demo mooier maakt, kan die handig zijn, maar verbetert die niet noodzakelijk het product.

Wat er meestal misgaat

Het probleem van de Sprint Review zit zelden erin dat het team niet kan laten zien wat er gedaan is. Het probleem is dat de gebeurtenis na verloop van tijd degenereert tot een eenzijdige demo: het team bereidt een presentatie voor, toont schermen, somt afgesloten taken op, de stakeholders knikken beleefd, iemand zegt "geweldig, dank je", en iedereen gaat uiteen. De Backlog verandert daarbij niet. Scrum.org behandelt dit antipatroon rechtstreeks in het materiaal Myth 12: The Sprint Review is a Demo: een demo kan deel uitmaken van de gebeurtenis, maar het doel van de Sprint Review is feedback maximaliseren en risico verlagen, niet een presentatie houden.

Dan begint de meeting tegen zijn eigen doel te werken. Het team bespreekt hoe het mooier gepresenteerd kan worden, in plaats van wat er belangrijk is om te bespreken. Stakeholders krijgen geen kans om feedback te geven, omdat het team "naïef opgaat in zijn eigen presentatie" — Scrum.org merkt dit apart op in het materiaal How to Engage Stakeholders in your Sprint Reviews. Oncomfortabele vragen worden niet gesteld. De kloof tussen wat er gebouwd is en wat de markt nodig heeft, komt laat aan het licht. De Product Backlog blijft zoals hij was vóór de meeting, terwijl het hele doel van de gebeurtenis is om hem te veranderen op basis van nieuwe gegevens.

In een AI-assisted context kan dit probleem versterken. Als het model elke sprint een presentatie, release notes en een lijst met prestaties genereert, raakt het team snel gewend aan de gedachte dat "de review al voorbereid is". Dan wordt de Sprint Review nog soepeler: AI-slides geopend, release notes gelezen, metrieken getoond, een beleefd "dank je" ontvangen en de meeting gesloten.

Het ziet er professioneel uit. Maar de vraag is niet hoe samenhangend de presentatie in elkaar zit. De vraag is of het team zijn Product Backlog heeft veranderd als de realiteit is veranderd.

Waar AI echt helpt

AI heeft in de Sprint Review een heel praktische zone van nut. Het kan de routine van de voorbereiding wegnemen en naar boven halen wat het team aan het einde van de sprint gemakkelijk verliest. Dit is vooral waardevol wanneer er veel bronnen zijn: issue tracker, pull requests, CI/CD, productanalytics, supporttickets, reviews uit de stores, enquêteresultaten, opnames van gebruikersinterviews.

Maar hier is het belangrijk om niet te veel te beloven. Zelfs de recente DORA State of AI-assisted Software Development 2025 beschrijft AI eerder als een versterker van bestaande organisatorische praktijken dan als een zelfstandige garantie voor betere delivery. Voor de Sprint Review betekent dit iets simpels: als het team al een eerlijk gesprek over waarde kan voeren en de backlog kan aanpassen, maakt AI de ingang naar dat gesprek rijker. Als de Sprint Review allang een demo-ritueel is geworden, maakt AI dat ritueel gewoon sneller en mooier.

Een goede AI-assistent verzamelt vóór de Sprint Review niet "hoe we het effectiever kunnen tonen", maar nuttige context voor een beslissing over het product:

• wat er echt in het product is veranderd tijdens de sprint en hoe dat samenhangt met het Product Goal;
• welke elementen van het increment klaar zijn voor inspectie en welke je beter eerlijk als onvoltooid kunt tonen;
• wat de productmetrieken zeggen na eerdere releases;
• welke feedback er van gebruikers en support is gekomen, inclusief tegenstrijdige en ongemakkelijke;
• welke hypotheses van eerdere sprints bevestigd zijn en welke niet;
• welke openstaande productvragen het waard zijn om met stakeholders te bespreken;
• welke items in de Product Backlog mogelijk hun actualiteit hebben verloren of juist in prioriteit zijn gestegen.

In zo'n modus vervangt AI de Sprint Review niet. Het verlaagt de kosten van de voorbereiding erop. Het team komt niet met ruwe data en niet met haastig verzamelde slides, maar met een al gestructureerd beeld: hier is het resultaat, hier zijn de gegevens, hier is de feedback, hier zijn de openstaande vragen. Dat maakt het mogelijk minder tijd te besteden aan het verzamelen van feiten en meer aan het gesprek "wat veranderen we nu in het product?".

Dit zet de logica van eerdere artikelen in de serie voort. In refinement hielp AI om materiaal voor de bespreking te verzamelen. In planning — varianten van het plan. In de Daily Scrum — signalen over het verloop van de sprint. In de Sprint Review kan het het resultaat en de feedback verzamelen. Maar in alle vier de gevallen verdwijnt het menselijke deel niet: het team en de stakeholders moeten controleren wat belangrijk is, wat er is veranderd en welk besluit er genomen moet worden.

Waarom AI de Sprint Review niet tot demo-theater mag maken

De gevaarlijkste versie van een AI-assisted Sprint Review ziet er zeer overtuigend uit: het model genereert een presentatie met mooie slides, samenhangende release notes, een lijst met "belangrijkste prestaties van de sprint", metrieken-grafieken en een soepele samenvatting van gebruikersfeedback. Soms wordt er een automatische voorspelling over het Product Goal en voorgestelde wijzigingen in de backlog aan toegevoegd.

Vanuit formele transparantie is dit handig. Vanuit Scrum kan dit een degradatie zijn.

Ten eerste versterkt zo'n formaat de eenzijdigheid. Hoe mooier de AI-demo, hoe sterker de verleiding om de meeting als presentatie te "houden". De aandacht verschuift van feedback naar vertoning: het team verdedigt de slides in plaats van stakeholders uit te nodigen tot een debat over waarde.

Ten tweede kan een AI-samenvatting van feedback juist dat wegvagen waarvoor de Sprint Review wordt gehouden. De echte waarde van feedback zit in tegenstrijdigheden, zwakke signalen, ongemakkelijke onenigheid en een zeldzame maar belangrijke opmerking. Een soepele gemiddelde samenvatting gooit gemakkelijk uitschieters weg, terwijl in een product juist de uitschieter vaak het signaal is. Dit is het klassieke risico van information integrity en misinformation, beschreven in het NIST-profiel voor generatieve AI.

Ten derde kan het model met vertrouwen inzichten verzinnen die niet in de data zitten. Confabulatie is vooral gevaarlijk in de Sprint Review, omdat een gegenereerde 'conclusie' over gebruikers gemakkelijk een productbeslissing wordt. Als AI schrijft 'gebruikers vragen om X', terwijl het in werkelijkheid twee tickets en één interview waren, riskeert het team de Product Backlog te wijzigen op basis van een hallucinatie.

Ten vierde kan het team productoordeel gaan delegeren aan de tool. Als AI wijzigingen in de backlog voorstelt, lijkt het of ze gewoon kunnen worden overgenomen. Als AI zegt dat het Product Goal wordt bereikt, lijkt het of er niets te bespreken valt. Dit is geen automatisering van de Sprint Review, maar het verschuiven van verantwoordelijkheid naar waar die niet kan liggen: voor het product is de Product Owner samen met het team verantwoordelijk, niet het model.

“Een AI-demo kan een nuttige input zijn. Het mag geen vervanging worden van het gesprek over waarde.”

We vervolgen de casus: B2B LMS en e-mailherinneringen

We nemen dezelfde casus uit de eerdere artikelen: een B2B LMS-platform, verplichte cursussen, e-mailherinneringen aan medewerkers die de verplichte cursus niet vóór de deadline hebben afgerond. Op de planning koos het team een nauw Sprint Goal: het systeem stuurt één correcte herinnering aan actieve medewerkers met een onvoltooide verplichte cursus vóór de deadline en bewaart een verifieerbare verzendgeschiedenis.

Zonder AI kan een Sprint Review in zo'n sprint gemakkelijk afglijden naar een demo. Het team toont het instelscherm voor herinneringen, demonstreert een testmail, zegt 'de planner werkt, deduplicatie is geregeld, het geschiedenislog wordt bijgehouden', de stakeholders knikken, iemand prijst het ontwerp van de mail. Formeel is alles goed. De Backlog verandert niet.

Maar het team kan het belangrijkste missen: herinneringen worden verstuurd, maar de openratio is laag omdat het onderwerp van de mail ongelukkig is; de supportafdeling heeft al meerdere meldingen gekregen 'waarom kreeg ik een herinnering voor een cursus die ik niet hoef te volgen' — dat wil zeggen, de eligibility-grens werkt niet zoals verwacht; één grote klant vraagt om een individueel schema, en dat verandert mogelijk de prioriteiten van de volgende sprint; en de interpretatie van de status expired, die het team als buiten scope beschouwde, is in werkelijkheid belangrijk voor de stakeholders.

AI kan hier helpen. Vóór de Sprint Review verzamelt het input: wat is verstuurd en naar wie, wat is de open- en klikratio, welke meldingen zijn bij support binnengekomen en waarover gaan ze, welke feedback hebben pilotklanten gegeven, welke backlog-items hangen samen met dit Sprint Goal. Dit is goed materiaal voor het gesprek.

Maar waarde ontstaat pas in de meeting, wanneer het team en de stakeholders de volgende stap zetten: beslissen dat een lage openratio een productprobleem is, geen cosmetica; dat de eligibility-grens verduidelijkt moet worden en als apart backlog-item moet worden opgenomen; dat individuele schema's voor grote klanten een strategische beslissing zijn, geen snelle fix; en dat de interpretatie van expired nu van 'buiten scope' naar de eerstvolgende prioriteit moet worden verplaatst. AI gaf resultaat en data. Het team heeft samen met de stakeholders de Product Backlog aangepast.

Anti-patterns

Hieronder staan enkele anti-patterns die ik bij de invoering van AI in de Sprint Review apart zou volgen.

1. AI maakt de presentatie mooier, maar de meeting blijft eenrichtingsverkeer

Als de inspanning naar het polijsten van slides en release notes gaat, wordt de Sprint Review versterkt als demo, niet als working session. Nuttiger is dat AI vragen aan stakeholders en open productthema's voorbereidt, niet alleen een effectvolle show van wat gedaan is.

2. Een AI-samenvatting van feedback middelt en verliest zwakke signalen

Een gladde samenvatting leest prettig, maar is gevaarlijk omdat ze tegenstrijdigheden en zeldzame maar belangrijke opmerkingen weggooit. Feedback kun je beter brengen met behoud van onenigheid en uitschieters, niet alleen een gemiddelde 'algemene stemming'.

3. AI verzint productinzichten die niet in de data zitten

'Gebruikers willen X' klinkt overtuigend, maar vereist controle: op hoeveel signalen is de conclusie gebaseerd, is dit geen hallucinatie, heeft het een zeldzaam geval niet vervangen door massale vraag. Een inzicht van het model is een hypothese, geen beslissing.

4. Metrieken worden getoond als prestatie, niet als aanleiding voor een beslissing

'10 000 mails verstuurd' is activiteit, geen waarde. De Sprint Review moet metrieken verbinden met het Product Goal en vragen wat ze veranderen in het plan, niet ze gebruiken als bewijs dat de sprint goed is verlopen.

5. AI stelt wijzigingen in de Product Backlog voor, en ze worden zonder discussie overgenomen

Een voorstel van het model kan een nuttige input zijn, maar het aanpassen van de backlog is een productbeslissing van de Product Owner samen met het team en de stakeholders, niet het automatisch toepassen van AI-aanbevelingen.

6. Demo-theater voor het management in plaats van inspectie om te adapteren

Als de Sprint Review een show wordt van 'we laten het management zien dat we goed bezig zijn', maakt AI de show alleen overtuigender. Dat ondermijnt het vertrouwen in het event en ontneemt het team eerlijke feedback.

Hoe de rollen veranderen

AI schrapt de rollen binnen het Scrum Team niet, maar verlegt het accent in de voorbereiding en uitvoering van de Sprint Review. Minder waarde in het handmatig samenstellen van de presentatie. Meer waarde in eerlijke inspectie van het resultaat, werken met feedback en samen beslissen over het product.

Rol	Risico bij een slecht AI-scenario	Volwassen gebruik van AI
Product Owner	Accepteert AI-feedbackoverzicht en voorgestelde backlogwijzigingen als kant-en-klare oplossing en stopt zelf met nadenken over de waarde.	Gebruikt AI-invoer als materiaal, maar voert zelf het gesprek over waarde, verifieert inzichten en is verantwoordelijk voor de aanpassing van de Product Backlog.
Ontwikkelaars	Verspillen voorbereiding aan het oppoetsen van een AI-demo in plaats van eerlijk te laten zien wat klaar is en wat niet.	Gebruiken AI om snel resultaat en risico's te verzamelen en inspecteren het increment eerlijk samen met de stakeholders.
Scrum Master	Draagt de facilitatie over aan slides en let alleen op de timing van de presentatie.	Beschermt de Sprint Review tegen verandering in een demo, helpt stakeholders te betrekken en de focus op aanpassing te houden.
Stakeholders	Krijgen een gladde AI-demo, knikken beleefd en geven geen echte feedback.	Zien het eerlijke resultaat en de data, stellen ongemakkelijke vragen en beïnvloeden de productprioriteiten.
Kwaliteitsingenieur / QA-ingenieur	Bevestigt de AI-lijst van 'gedaan' en creëert de schijn van gereedheid van het increment.	Helpt eerlijk te laten zien wat aan de Definition of Done voldoet en wat niet, en waar kwaliteitsrisico's blijven.
UX/UI-ontwerper	Valt buiten het overzicht omdat de AI-demo zich richt op functies en metrieken.	Brengt gebruikersobservaties en feedback over de ervaring in en helpt het resultaat te verbinden met echte waarde.

Praktisch filter voor AI-assisted Sprint Review

Ik zou niet beginnen met het invoeren van een 'AI-demo-generator'. Ik zou beginnen met een nauwere vraag: welke invoer helpt het team en de stakeholders sneller een eerlijk productbesluit te nemen? Daarna kan AI worden gebruikt als voorbereidende laag, niet als vervanging van het event.

AI-invoer voor de Sprint Review is nuttig als het helpt de volgende vragen te beantwoorden:

• Wat is er echt veranderd in het product en hoe verhoudt dat zich tot het Product Goal?
• Wat is klaar voor eerlijke inspectie en wat moet als onvoltooid worden getoond?
• Wat zeggen de data en feedback, inclusief tegenstrijdige?
• Welke hypotheses zijn bevestigd en welke zijn mislukt?
• Welke openstaande productvragen moeten met de stakeholders worden besproken?
• Welke items in de Product Backlog moeten worden gewijzigd, toegevoegd of verwijderd?
• Welk besluit nemen we op basis van de uitkomsten, en niet alleen wat we laten zien?

En omgekeerd: als AI-invoer vooral de vraag beantwoordt 'hoe kunnen we het gedane effectvoller tonen', is dit geen Sprint Review. Dit is een demo. Die kan nuttig zijn voor communicatie, maar moet niet worden verward met inspectie van het resultaat en aanpassing van de Product Backlog.

Databeheer en -hygiëne

De Sprint Review is bijzonder gevoelig voor data, omdat AI-voorbereiding gemakkelijk feedback begint te verzamelen uit supporttickets, CRM, interviewopnames, enquêtes, reviews in appstores en klantcorrespondentie. Hoe breder de toegang, hoe overtuigender het overzicht. Maar hoe hoger het risico op lekken van gevoelige informatie, verdraaiing van betekenis en overmatige afhankelijkheid van een zelfverzekerde maar onvolledige modeluitvoer. Deze risicoklassen zijn goed beschreven in het NIST-profiel voor generatieve AI, in het NIST-framework voor AI-risicobeheer 1.0 en in de OWASP Top 10 for LLM Applications 2025.

Het team moet vooraf afspreken welke feedbackbronnen zijn toegestaan voor AI, hoe gebruikersdata worden geanonimiseerd, wie het gegenereerde overzicht ziet en of ruwe klantcitaten aan externe stakeholders mogen worden getoond. Bij het werken met persoonsgegevens van gebruikers en klanten zijn richtlijnen zoals EDPB Opinion 28/2024 en ICO monitoring at work impact assessment nuttig — niet als juridische instructie voor het artikel, maar als herinnering aan rechtsgrond, dataminimalisatie, transparantie en proportionaliteit.

Praktisch betekent dit: trek geen onnodige persoonsgegevens in het model, scheid feiten van gegenereerde interpretaties, markeer AI-inzichten als hypotheses, verifieer gebruikerscitaten bij de primaire bron en toon op de Sprint Review geen 'conclusies' die niet met data kunnen worden onderbouwd. AI moet het team helpen het resultaat en de feedback eerlijk te zien, niet een overtuigend maar ongeverifieerd beeld produceren.

Praktische conclusie

AI kan de Sprint Review inderdaad nuttiger maken. Het kan de routine van de voorbereiding wegnemen, het resultaat van de sprint vooraf verzamelen, dit aan metrieken koppelen, feedback aggregeren, discrepanties tussen plan en werkelijkheid belichten en onderwerpen voor bespreking met stakeholders aandragen.

Maar dit werkt alleen als het team de grens begrijpt: AI bereidt de invoer voor, maar houdt geen Sprint Review. Het helpt het resultaat en de data te zien, maar beslist niet wat ze voor het product betekenen. Het kan feedback verzamelen, maar creëert niet op zichzelf een eerlijk gesprek over waarde. Het kan wijzigingen in de backlog voorstellen, maar neemt geen verantwoordelijkheid voor het product.

Daarom zou ik de hoofdstelling zo formuleren: AI moet de kosten van voorbereiding verlagen, zodat team en stakeholders meer aandacht overhouden voor het gesprek over waarde en aanpassing van het plan. Als het omgekeerde gebeurt en de Sprint Review verandert in een gepolijste AI-demo, verliest het team precies dat waarvoor het event bestaat: eerlijke inspectie van het resultaat, echte feedback, gezamenlijke besluitvorming en verantwoordelijkheid voor het product.

Een volwassen team vraagt niet: ‘kunnen we AI de sprintreview laten samenstellen?’. Het vraagt anders: ‘welk deel van de routine rond de voorbereiding kan AI wegnemen, zodat onze Sprint Review een eerlijker gesprek wordt over waarde en over wat we in het product moeten veranderen?’. Dat is een minder flitsende formulering. Maar ze ligt dichter bij de echte productpraktijk.

Bronnen en richtlijnen

• Scrum Guide 2020 — Sprint Review, Product Goal, Product Backlog, increment, working session, inspectie en aanpassing.
• Scrum Guide Expanded v2026.1 — companion-bron op basis van de Scrum Guide 2020: praktische framing van de Sprint Review, waardestroom naar stakeholders en AI als supervised decision-making partner.
• Scrum.org: What is a Sprint Review? — Sprint Review als collaborative working session, niet als presentatie.
• Scrum.org: Myth 12 — The Sprint Review is a Demo — waarom een Sprint Review niet tot een demo beperkt mag blijven.
• Scrum.org: How to Engage Stakeholders in your Sprint Reviews — waarom feedback van stakeholders de belangrijkste waarde van het event is.
• NIST-profiel voor generatieve AI — confabulatie / zelfverzekerd verzinnen, information integrity, overmatige afhankelijkheid en menselijke controle.
• NIST AI Risk Management Framework 1.0 — governance / regulering, verantwoordingsplicht en configuratie van de mens-AI-interactie.
• OWASP Top 10 for LLM Applications 2025 — blootstelling van gevoelige informatie, misinformation en excessive agency in LLM-applicaties.
• DORA State of AI-assisted Software Development 2025 — AI als versterker van organisatorische praktijken, niet als zelfstandige garantie voor verbetering.
• EDPB Opinion 28/2024 en ICO monitoring at work impact assessment — richtlijnen voor persoonsgegevens, minimalisatie, transparantie en proportionaliteit bij het werken met feedback.