Wat is verwerken van feedback na de review?
Verwerken van feedback na de review is het vertalen van de ontvangen opmerkingen, vragen, verbeterpunten en wensen van stakeholders in concrete vervolgstappen voor het product en het team. Dit gebeurt direct na de Sprint Review of uiterlijk vóór de volgende Sprint Planning.
Bij verwerken van feedback hoort niet alleen “we schrijven het op”, maar vooral: begrijpen, beoordelen, prioriteren en inplannen.
Casus
Het team heeft in de review een nieuwe zoekfunctie laten zien. Stakeholders vinden het goed werken, maar ze missen sorteren op datum.
De Product Owner noteert: “Gebruiker wil zoekresultaten kunnen sorteren op datum (belangrijk voor dagelijks gebruik).”
De developers geven aan dat dit technisch haalbaar is binnen één sprint.
De Product Owner zet dit hoog op de product backlog omdat dit direct waarde toevoegt voor eindgebruikers.
Hoe zit verwerken van feedback in elkaar?
Het verwerken van feedback na een Sprint Review kent grofweg drie stappen: begrijpen, beoordelen en borgen.
Begrijpen
In deze stap zorgt het Scrumteam dat de feedback inhoudelijk goed begrepen is. Onduidelijke of vage feedback wordt verduidelijkt.
-
De Product Owner herformuleert feedback als behoefte van de gebruiker.
-
Het Development Team verduidelijkt de technische impact.
-
De Scrum Master bewaakt dat de discussie respectvol blijft en dat alle perspectieven gehoord blijven worden, zeker als er tegenstrijdige wensen zijn.
Voorbeeld
Een stakeholder zegt in de review: “Dit dashboard voelt druk.”
Bij verwerken van feedback wordt dat vertaald naar een concrete observatie: “Gebruiker vindt de grafieken en KPI-tegels te dicht op elkaar; behoefte aan minder visuele ruis.”
Dit kan later vertaald worden naar een backlogitem zoals: “Als gebruiker wil ik een overzichtelijk dashboard met minder elementen tegelijk in beeld, zodat ik sneller zie wat belangrijk is.”
Beoordelen
In deze stap bepaalt het team wat er met de feedback gebeurt. Niet alle feedback wordt direct verwerkt.
Bij het beoordelen van feedback wordt gekeken naar:
-
Productwaarde: Levert dit meer waarde op voor de gebruiker of opdrachtgever?
-
Urgentie: Moet dit nu opgelost worden of kan het wachten?
-
Impact op het productdoel / sprintdoel: Past dit bij waar het team naartoe werkt?
-
Technische haalbaarheid en risico: Is dit klein en snel te bouwen of vraagt dit een grotere herziening?
De Product Owner is verantwoordelijk voor de uiteindelijke prioriteit op de product backlog. Het Development Team adviseert over technische consequenties zoals complexiteit, risico en afhankelijkheden.
Voorbeeld
Feedback: “Kan de export ook naar Excel in plaats van alleen PDF?”
Beoordeling:
-
Product Owner: “Excel-export verhoogt bruikbaarheid voor 80% van de gebruikers.”
-
Development Team: “Technisch haalbaar binnen 1 à 2 dagen, laag risico.”
Resultaat: dit wordt bovenaan de product backlog geplaatst.
Tegenvoorbeeld
Feedback: “Kunnen we ook een compleet nieuw rechtenmodel met per-gebruiker-toegang?”
Beoordeling:
-
Grote scope, raakt security, auditing, beheer.
-
Past niet in de komende sprints zonder herontwerp.
Resultaat: dit wordt als groter thema vastgelegd, maar niet direct ingepland.
Borgen
In deze stap wordt de beoordeelde feedback vastgelegd op een manier die bruikbaar is voor toekomstige sprints.
Bij het borgen van feedback hoort:
-
Het vertalen van feedback naar duidelijke backlogitems (inclusief gewenste waarde voor de gebruiker).
-
Het koppelen van de feedback aan bestaande items als het om een verbetering van iets bestaands gaat.
-
Het markeren van risico’s of afhankelijkheden die later aandacht vragen.
Belangrijk hierbij:
-
Een backlogitem mag nooit alleen technisch klinken (“Zoekfunctie optimaliseren”), maar moet de reden bevatten (“Zodat gebruiker sneller kan vinden wat hij zoekt in lange lijsten”).
-
De oorspronkelijke feedbackbron (bijv. een specifieke stakeholdergroep) wordt genoteerd, zodat later gecontroleerd kan worden of de aanpassing voldoet aan de verwachting.
Hoe gebruik je verwerken van feedback in SCRUM?
Het verwerken van feedback is geen losse administratieve taak, maar direct input voor het vervolg van het Scrumproces.
Casus
Tijdens de Sprint Review (einde sprint) op 24 oktober laat het team een nieuwe rapportagepagina zien. De stakeholders geven drie belangrijke punten:
De rapportage moet ook per afdeling te filteren zijn.
Het downloaden duurt soms te lang.
De terminologie op het scherm sluit nog niet aan op wat in de organisatie wordt gebruikt.
Mogelijke uitwerking van de casus
Stap 1. Begrijpen
-
Het team verduidelijkt samen met de stakeholders wat “per afdeling filteren” betekent.
-
Het team vraagt: “Welke termen horen we precies op het scherm te gebruiken?” en legt dit vast.
Stap 2. Beoordelen
-
De Product Owner bespreekt met het team dat filteren per afdeling direct waarde levert voor managers, en daarom prioriteit krijgt.
-
Het Development Team legt uit dat de downloadtijd deels een infrastructuur-issue is. Dit vraagt onderzoek en kan niet blind ingepland worden als “kleine bug”.
-
De Scrum Master benoemt dat de verkeerde terminologie tot misinterpretatie kan leiden bij eindgebruikers. Dat raakt bruikbaarheid, dus dit komt ook hoog op de backlog.
Stap 3. Borgen
-
Er worden drie backlogitems toegevoegd of bijgewerkt:
-
“Als afdelingsmanager wil ik kunnen filteren op mijn eigen afdeling, zodat ik alleen mijn eigen cijfers zie.”
-
“Onderzoek verbeteren performance downloadrapport (technische spike, max 1 dag onderzoek, opleveren bevindingen).”
-
“Pas terminologie aan naar de begrippenlijst van de klant zodat schermteksten herkenbaar zijn.”
-
-
Elk backlogitem krijgt een eerste definitie van wanneer het ‘klaar’ is (acceptatiecriteria), zodat de feedback later toetsbaar is tijdens de volgende review.
Daarna:
-
Deze nieuwe of aangepaste backlogitems worden meegenomen in de volgende Sprint Planning.
-
Tijdens de eerstvolgende Sprint Review wordt expliciet teruggekoppeld: “Vorige keer vroegen jullie X. We hebben Y gedaan. Lost dit jullie probleem op?”
Dit laat zien dat het team luistert en vergroot vertrouwen.
Belangrijk om te onthouden bij verwerken van feedback:
-
Verwerken van feedback gebeurt samen met de Product Owner. De Product Owner beslist over prioriteit, maar doet dat transparant richting stakeholders.
-
Verwerken van feedback is niet hetzelfde als “alles beloven”. Het is normaal om feedback te parkeren of op te knippen.
-
Verwerken van feedback levert bruikbare items op de product backlog op, geen losse notities in een chat of meetingdocument.
-
Verwerken van feedback wordt zichtbaar gemaakt in de volgende review. Dit sluit aan bij transparantie en inspectie zoals beschreven in SCRUM.
Volgende stap: Uitleg kiezen werkvorm