Backlog Refinement en AI: wat verandert er echt

Een praktische analyse van hoe AI Backlog Refinement verandert: wat versnelt, waar ontstaan risico's, hoe de tijd van het team wordt herverdeeld en wat handmatig moet worden gecontroleerd.

26 Mar 2026 · 06:54 UTC24 min leestijd

Telegram Origineel

Dit is het eerste artikel uit een reeks over hoe AI de klassieke bijeenkomsten van een cross-functioneel ontwikkelingsteam verandert. Hieronder begin ik met Backlog Refinement, en in de volgende materialen behandel ik afzonderlijk Planning, Daily, Review, Retrospective en daarna bundel ik alles in een afsluitend overzichtsartikel.

Laat ik meteen het kader verduidelijken: hieronder heb ik het over refinement als een regelmatige teamsessie en de praktijk van het verfijnen van backlog items, niet per se als een apart officieel Scrum-event. Dat is belangrijk voor de terminologische nauwkeurigheid: in de Scrum Guide 2020 (RU PDF) wordt refinement beschreven als een ongoing activity, niet als een zelfstandig event. In de Russische versie van de Scrum Guide 2020 wordt deze gedachte direct geformuleerd: het verfijnen van de Product Backlog is een voortdurende activiteit om details, volgorde en omvang toe te voegen.

Backlog Refinement is een van de eerste plekken waar AI het team heel tastbaar voordeel begint op te leveren. Het helpt sneller context te verzamelen, een concept van de probleemstelling voor te bereiden, snel een concept van acceptatiecriteria te genereren, vergelijkbare cases te vinden en een lijst met open vragen te formuleren. Deze stelling wordt ook ondersteund door meer toegepaste werken: bijvoorbeeld in LLM-Assisted Requirements Engineering in Agile MDD werd de generatie van acceptance criteria apart gevalideerd, en in de industriële case Acceptance Test Generation with Large Language Models merkten gebruikers op dat AI-scenario's hielpen om eerder gemiste gevallen op te merken. Maar juist daarom is het hier extra makkelijk om in de val te trappen: een goed opgesteld concept verwarren met een daadwerkelijk begrijpelijke taak.

Naar mijn mening vereenvoudigt AI refinement niet in de zin dat het team nu minder hoeft na te denken. Het maakt veeleer het duurste handmatige werk eromheen goedkoper — zoeken, samenvatten, verpakken en de eerste decompositie. En dus verdwijnt de waarde van de teamdiscussie zelf niet, maar verschuift die: er gaat minder tijd naar het uit chaos iets laten ontstaan dat op een taak lijkt, en meer naar het begrijpen of dit überhaupt in behandeling kan worden genomen.

“AI versnelt niet de afspraak van het team zelf, maar de voorbereiding van het materiaal ervoor”

Waarom de veranderingen juist bij Backlog Refinement als eerste voelbaar zijn

Als je kijkt naar de gebruikelijke teamrituelen en bijeenkomsten in de Agile-praktijk, blijkt refinement een van de meest gevoelige te zijn voor de komst van AI. De reden is vrij eenvoudig: rond refinement was historisch veel handmatige intellectuele routine. Je moet verspreide context verzamelen uit documenten, oude tickets, chats en het geheugen van mensen. Je moet een ruw zakelijk idee omzetten in een begrijpelijk backlog item. Je moet het bedrijfsprobleem, het scenario, de acceptatiecriteria, beperkingen, open vragen, afhankelijkheden en mogelijke grensgevallen formuleren.

Juist in deze laag past AI bijzonder goed. Dat sluit ook aan bij hoe vandaag de toepassing van LLM's in requirements engineering wordt besproken: modellen zijn sterk in samenvatten, eerste structurering van requirements, het genereren van concepten en ondersteuning van analytische voorbereiding, maar zwakker waar domeinprecisie, traceerbaarheid en verantwoordelijkheid voor definitieve beslissingen nodig zijn. In die zin wordt refinement inderdaad een van de eerste processen waar het nut van AI snel voelbaar is, en de grenzen van de betrouwbaarheid ervan bijna meteen. Hierover wordt goed geschreven in het overzicht Challenges in applying large language models to requirements engineering tasks, in het recente systematische overzicht Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review, en in het meer toegepaste werk LLM-Assisted Requirements Engineering in Agile MDD.

Het team analyseert een backlog item met behulp van AI en Agile-artefacten — AI versnelt de voorbereiding op refinement goed, maar vervangt de collectieve controle van de betekenis niet.

Hoe refinement er vóór AI uitzag

Simpel gezegd was refinement vóór AI heel vaak een proces van handmatig begrip samenstellen. In de backlog belandde niet een kant-en-klare taak, maar eerder een zakelijke intentie: onboarding verbeteren, herinneringen toevoegen, de manager een nieuw rapport geven, het aantal achterstallige verzoeken verminderen. Daarna begon de Product Owner, analist of iemand van de leads handmatig context te verzamelen: oude klantverzoeken werden opgezocht, vergelijkbare features, beperkingen van de huidige architectuur, geldende statussen, bestaande notificaties, UI-patronen en al het andere dat plotseling in de discussie naar boven kon komen.

Vervolgens probeerde dezelfde persoon of een paar mensen handmatig het verzamelde materiaal om te zetten in een eerste concept: de bedrijfsproblematiek formuleren, het scenario beschrijven, acceptatiecriteria schrijven, openstaande vragen benoemen en mogelijke beperkingen aangeven. Maar zelfs als zo'n concept al bestond, ging de bijeenkomst vaak toch op aan het weer in het hoofd van het hele team brengen van de context. De product owner legde opnieuw uit wat het bedrijf wil, de analist vertelde wat al duidelijk was geworden, de ontwikkelaars brachten architecturale beperkingen in, QA haalde grensgevallen naar boven, de designer en frontend bespraken of er een apart scherm nodig was en waar dat dan zou moeten leven.

Dezelfde casus: zonder AI en met AI

Om niet op het niveau van algemene formules te blijven, neem ik een concrete casus. Het product is een B2B LMS-platform voor bedrijfsopleidingen. Grote klanten wijzen medewerkers verplichte cursussen toe over compliance, veiligheid en interne reglementen. Vanuit het bedrijf komt de vraag: er moeten automatische e-mailherinneringen worden toegevoegd voor medewerkers die een verplichte cursus niet vóór de deadline hebben afgerond.

Op het eerste gezicht lijkt dit een eenvoudige taak over het versturen van een e-mail. Maar al in de eerste stappen wordt duidelijk dat er in werkelijkheid veel vertakkingen zijn: wie precies als niet-afgerond geldt, wanneer herinneringen moeten worden verstuurd, hoe verzendingen moeten worden gededupliceerd, hoe de klant dit instelt, of er een verzendlog nodig is, wat te doen met tijdzones, welke taal de e-mail moet hebben en of gearchiveerde en gedeactiveerde gebruikers moeten worden uitgesloten.

In de modus zonder AI kwam het team tot deze vragen vooral via een lange handmatige voorbereiding en een omvangrijk gesprek tijdens de bijeenkomst zelf. Eerst bracht de product owner de klantcontext in. Daarna ging de analist handmatig door interne materialen: zocht oude vergelijkbare verzoeken, bekeek de notificatiedienst, controleerde de huidige statussen van assignments, de aanwezigheid van schedulertaken, velden voor taalinstelling en tijdzone. Al in deze fase kwamen echte beperkingen naar boven: het systeem heeft e-mailsjablonen, maar alleen voor transactionele e-mails; de tijdzone wordt op klantniveau opgeslagen, niet op gebruikersniveau; er zijn geen verzendlogs; en er is ook geen apart model voor herinneringen in het product.

Daarna stelde de analist handmatig een eerste concept van de specificatie samen, maar dat bleef toch onvolwassen. Er konden bijvoorbeeld nog geen exacte statussen in zijn vastgelegd op basis waarvan herinneringen moeten worden verstuurd, de deduplicatielogica, de minimale omvang van het werk voor de UI, de fallback voor taal of de grenzen van de eerste versie. En tijdens de refinement verzamelde het team de taak alsnog tijdens het gesprek. Daar werd duidelijk dat herinneringen alleen nodig zijn voor verplichte cursussen, dat de statussen not_started en in_progress geschikt zijn, maar dat expired beter niet in de eerste versie kan worden meegenomen, dat zonder verzendjournaal de support en het klantbegeleidingsteam snel zouden verdrinken in vragen, en dat er zonder aparte bescherming duplicaten zouden ontstaan bij het opnieuw uitvoeren van schedulertaken.

In de modus met AI ziet dezelfde casus er anders uit. De product owner laadt in de AI een korte samenvatting van het klantbegeleidingsteam, de laatste klantvragen en het ruwe oorspronkelijke verzoek. De AI groepeert snel de pijnpunten van klanten, haalt terugkerende verwachtingen eruit en helpt de probleemformulering op te stellen. De analist vraagt de AI alles naar boven te halen wat verband houdt met notificatiestromen, toewijzingsstatussen, schedulertaken, taalinstelling, tijdzone en vergelijkbare taken in Jira. De backend laat vooraf via de AI de beschrijving van de huidige notificatiearchitectuur doorlopen en vraagt om een technische aanpak voor te stellen. De frontend en designer controleren snel waar de instellingen en de verzendgeschiedenis het logischst kunnen worden ingebouwd. QA haalt een eerste lijst met grensgevallen en tijdsrisico's naar boven.

Hier komt meestal een natuurlijke vraag op: wat als de AI iets heeft gemist? Hoeveel kun je zo'n korte samenvatting eigenlijk vertrouwen, vooral wanneer de bronbasis groot is? Onderzoek en praktijkcases geven hier een tamelijk nuchter beeld: LLM's kunnen inderdaad het genereren van user stories, concept-acceptatiecriteria en eerste specificaties versnellen, maar de kwaliteit van het resultaat hangt sterk af van de inputcontext, het domein en de daaropvolgende menselijke controle. Daarom is het nuttig ook meer toegepaste werken in gedachten te houden, zoals AI-Generated User Stories: Are They Good Enough? en LLM-Assisted Requirements Engineering in Agile MDD: die laten goed zien dat het genereren van een sterk concept en klaar zijn voor ontwikkeling niet hetzelfde zijn.

По моему опыту работы с Cursor, в прикладных сценариях я довольно редко сомневаюсь в том, что модель способна собрать нужный первый проход по большому массиву источников. Гораздо важнее другое: насколько хорошо я сформулировал задачу, какие ограничения задал, какие уточняющие вопросы успел добавить и как именно организовал проверку результата. Когда у меня возникает сомнение, я не пытаюсь решить его вопросом «верю или не верю AI» — я просто доуточняю запрос, прошу отдельно показать источники, вынести спорные места, разделить факты и предположения или пересобрать ответ с другой рамкой. В этом смысле работа с AI очень похожа на коучинг: полезен навык задавать точные вопросы, которые не просто запускают генерацию, а направляют мышление модели в нужную сторону.

Это, конечно, мой личный опыт, а не универсальное правило. Возможно, я отдельно напишу ещё один материал именно про доверие к AI, качество уточняющих вопросов и управляемую проверку результата. Для refinement это особенно важно: чем больше база источников и чем убедительнее краткое резюме, тем выше риск перепутать сильную подготовку с уже проверенным пониманием.

“Чем больше база источников и чем убедительнее краткое резюме, тем выше риск перепутать сильную подготовку с уже проверенным пониманием”

В результате команда приходит на refinement уже не с сырой идеей, а с довольно сильной заготовкой: есть черновик пользовательской истории, черновик критериев приёмки, открытые вопросы, список рисков, предварительный технический подход и UI-предложение. Поэтому сама встреча становится короче и предметнее. Команда уже не тратит столько времени на поднятие базового контекста и обсуждает в основном спорные места: включать ли expired, делать ли отдельный часовой пояс на пользователя, нужен ли журнал отправок в первом релизе, ограничиться ли фиксированными триггерами, как защититься от дублей и что считать границами первой версии.

В чем заключается прогресс команды?

Когда команда только начинает использовать AI, он в основном работает как быстрый генератор первого черновика. Но по мере зрелости следующий логичный шаг — перестать работать только с общей моделью и начать постепенно переносить в управляемый контекст команды то, что раньше жило только в памяти людей. Это могут быть продуктовые принципы, шаблоны критериев приёмки, частые причины отказа задачи на refinement, типовые граничные случаи, архитектурные ограничения, набор типовых уточняющих вопросов, внутренние регламенты организации, Definition of Ready и Definition of Done на уровне организации и команды, а также примеры хороших решений по похожим кейсам.

Тогда качество первого черновика действительно начинает расти. Не потому, что модель внезапно “поняла домен сама”, а потому, что команда научилась системно выгружать в неё собственные паттерны мышления, внутренние ограничения и правила проверки. И здесь refinement становится не только местом проверки задачи, но и местом, где команда постепенно обучает свой собственный AI-слой.

Что меняется по ролям

Ниже полезно смотреть не только на роли как на абстрактные функции, но и на конкретные действия в смоделированном кейсе с напоминаниями по обязательным курсам. Именно так разница между режимом без AI и с AI становится заметной по-настоящему.

Роль	Без AI	С AI
Владелец продукта	Поднимает клиентский контекст вручную, сводит запросы команда сопровождения клиентов, заново объясняет бизнес-проблему на встрече.	Готовит обезличенный вход, просит AI сгруппировать боли клиентов, приносит на встречу черновик формулировки проблемы и список спорных продуктовых решений.
Бизнес-аналитик	Ищет похожие кейсы, вручную собирает статусы, ограничения, зависимости и потом переписывает всё в первый черновик постановки.	Организует запрос к AI по источникам, сверяет краткое резюме с источниками, редактирует критерии приёмки, фиксирует открытые вопросы и то, что модель могла упустить.
Бэкенд-разработчик	Часто впервые глубоко вникает в проблему уже на refinement, поднимает ограничения сервиса уведомлений и риски дублей прямо по ходу обсуждения.	До встречи получает первый проход по техвариантам, заранее проверяет дедупликацию, задачи планировщика, audit trail и границы первой версии.
Фронтенд-разработчик	На встрече вместе с дизайнером пытается понять, нужен ли отдельный экран, где жить настройкам и что действительно входит в минимальный UI.	До встречи смотрит AI-черновик UI-встройки, заранее отмечает спорные места по настройкам, состояниям и ограничениям интерфейса.
Инженер по качеству / QA-инженер	Подключается в основном на встрече, вытаскивает негативные сценарии, статусные коллизии и временные риски уже в общем разговоре.	До встречи получает стартовый список граничных случаев, проверяет, что AI не пропустил дубли, тайм-зоны, языковые fallback-сценарии и исключения по статусам пользователей.
UX/UI-дизайнер	Разбирается в задаче по ходу обсуждения и на месте прикидывает, нужен ли новый экран, блок настроек или история отправок.	Test snel samen met de frontend meerdere varianten van een UI-aanpak en komt al met een doordacht voorstel in plaats van vanaf nul te beginnen.
Scrum master	Verzamelt deelnemers, houdt de timing in de gaten, helpt niet verdwaald te raken bij het chaotisch ophalen van context en brengt het team terug naar de kern wanneer de discussie uitwaaiert.	Besteedt minder tijd aan organisatorische mechaniek en het afstemmen van basiscontext, meer aan het faciliteren van betwiste beslissingen, het vastleggen van open vragen en het bewaken van de kwaliteit van de discussie.

Voordelen, risico's en vrijgemaakte tijd

Het nut van AI in refinement is behoorlijk merkbaar. Context wordt sneller verzameld, er verschijnt sneller een concept van de taak, de discussie start gemakkelijker en de resultaten worden beter verpakt. Maar juist in refinement komen de risico's van AI ook heel vroeg naar voren. Het meest voor de hand liggende risico is valse helderheid. AI kan nette backlog items maken die er visueel en structureel goed uitzien. Daardoor is het voor het team gemakkelijker zichzelf te misleiden met het gevoel dat de taak al begrepen is, terwijl er nog steeds product- en technische gaten in zitten.

Hier is het nuttig de dingen bij hun naam te noemen. Ten eerste is dat automatiseringsbias en overmatige afhankelijkheid — de neiging om de aanbeveling van het systeem te graag over te nemen en over te stappen van actieve verificatie naar passievere monitoring. In het NIST-profiel voor generatieve AI wordt dit direct beschreven als overmatig vertrouwen in AI-systemen, en in de empirische studie Automation Bias in AI-Decision Support: Results from an Empirical Study wordt aangetoond dat een hoge waargenomen bruikbaarheid van het systeem valse instemming met de fouten ervan kan verhogen, terwijl de kwaliteit van de training van gebruikers de kans op dat effect verlaagt. Ten tweede is dat de hallucinatie van het model — een plausibele maar niet door bronnen bevestigde conclusie. Voor refinement is dit extra kritisch, omdat AI bijna altijd werkt via samenvatting van documenten, tickets en correspondentie, en het risico dus niet alleen zit in een “mooi maar verzonnen concept van acceptatiecriteria”, maar ook in stille vertekening van de oorspronkelijke context. Daarom maakt AI in refinement vaker fouten niet in de stijl van de tekst, maar in de feiten van de context — en dat risico wordt goed beschreven in het werk On Faithfulness and Factuality in Abstractive Summarization. Een praktisch tegengif is hier vrij eenvoudig: vraag het model feiten van hypotheses te scheiden, eis verwijzingen naar bronnen en bouw een korte samenvatting zo op dat die snel terug te herleiden is tot documenten, tickets en beslissingen van het team.

Er is nog een risicolaag — data. In de bovenstaande casus werkt AI met klantverzoeken, interne systeembeschrijvingen en gebruikerssignalen. Daarom is het belangrijk dat het team vooraf afspreekt wat überhaupt aan het model mag worden doorgegeven en wat niet. Voor generative AI beperkt het risico zich niet tot alleen de prompt: persoonsgegevens kunnen in de input, in de output en zelfs via memorization/regurgitation van het model terechtkomen. Daarom moeten, als er persoonsgegevens of gevoelige klantcontext in het werk voorkomen, basisprincipes van datagezondheid verplicht zijn: minimaliseer de hoeveelheid data in prompts, pseudonimiseer de input waar mogelijk, trek geen ruwe export zonder filtering naar het model, begrijp expliciet het doel van de verwerking en neem beweringen van de provider zoals “wij verwerken geen persoonsgegevens” of “het model is anoniem” niet zomaar aan zonder verifieerbare organisatorische en technische controles. Apart is het nuttig vooraf de rechtsgrond voor verwerking vast te leggen, de minimaal noodzakelijke set velden, rollen en verantwoordelijkheden binnen het proces, en waar van toepassing — de vereisten voor het informeren van betrokkenen. Als het scenario persoonsgegevens omvat en de schaal of risico's merkbaar zijn, is het zinvol vooraf te beoordelen of een DPIA nodig is en dat besluit apart vast te leggen. In de Europese context sluit dit goed aan bij zowel de principes van GDPR Article 5, als bij de praktische aanbevelingen van CNIL over AI system development, en ook bij EDPS guidance on Generative AI en EDPB Opinion 28/2024.

En hier rijst nog een belangrijke vraag: waar gaat de vrijgemaakte tijd van specialisten naartoe. De eenvoudigste optie is proberen er nog meer taken in te proppen. Een volwassener optie is deze besparing te investeren in de kwaliteit van beslissingen, vermindering van technische schuld, ontwikkeling van interne sjablonen, opleiding, documentatie en op zijn minst beter beheer van de aandacht van het team. In het afsluitende overzichtsartikel van de serie zal ik apart vertellen dat AI niet alleen het proces verandert, maar ook de cultuur van het gebruik van teamtijd.

Nieuwe verborgen kosten die je niet kunt negeren

Om het gesprek over efficiëntie niet te glad te laten lijken, is het belangrijk ook de keerzijde toe te voegen: AI levert zelden “pure besparing” zonder nieuwe soorten werk. Een deel van de tijd gaat nu naar het voorbereiden van data, het instellen van toegang tot bronnen, het onderhouden van prompts en sjablonen, het verifiëren van bronnen, het documenteren van beslissingen en menselijke controle. Deze kijk sluit goed aan bij de praktijken van risk management voor generative AI: bijvoorbeeld het NIST-profiel voor generatieve AI legt niet alleen de nadruk op het voordeel van automatisering, maar ook op de noodzaak van oversight, documentation en managementcontrole.

Scenariomatige schatting van de werkuren voor één Backlog Refinement (scenariomatig)

Hieronder staat niet de “gemiddelde temperatuur van de markt”, maar een scenariomodel van hetzelfde Backlog Refinement voor hetzelfde team van zeven personen: PO, BA, backend, frontend, QA, designer en Scrum Master. Dit is een schatting van één groot of duidelijk onzeker backlog item, niet van een kleine, goed begrepen story. De waarde van deze cijfers zit niet in de nauwkeurigheid tot op de minuut, maar in de vergelijking van de kostenstructuur: waar de tijd vroeger naartoe ging en waar die nu naartoe gaat.

Hierna gaat het specifiek over mensuren per één groot backlog item — voorbereiding, bespreking en korte nabewerking na de meeting — en niet over de duur van de meeting zelf. De meeting zelf wordt meestal ook korter, maar een deel van het werk verhuist gewoon naar asynchrone voorbereiding, verduidelijkende runs en verplichte handmatige controle.

Opmerking bij de berekening van de werkuren: historisch werd in Scrum Guide 2017 (RU PDF) refinement ook beschreven als ongoing process, en daar stond een richtlijn dat het gewoonlijk niet meer dan 10% van de beschikbare capaciteit van het ontwikkelingsteam in beslag neemt. In Scrum Guide 2020 (RU PDF) staat die richtlijn niet meer, dus de tabel hieronder kun je beter niet als norm lezen, maar als scenariomodel om twee werkwijzen te vergelijken.

Belangrijk om apart toe te lichten: de kolom ‘Met AI’ hieronder bevat al het basale nieuwe werk zonder welke dit scenario niet werkt — het voorbereiden van invoergegevens, verduidelijkende vragen, de eerste controle van de korte samenvatting, verificatie van betwiste punten en minimale menselijke controle. Het uiteindelijke voordeel in de tabel is dus niet de “ruwe” besparing vóór verrekening van de nieuwe kosten, maar een al realistischer scenariomatige schatting nadat die basaal zijn meegenomen.

Om deze schatting reproduceerbaar te maken, is het handig om die volgens een eenvoudig schema te berekenen: T_AI = T_base × ((1 − p) + p × s) + o，waar T_base — tijd zonder AI, p — aandeel versnelbaar werk, s — versnellingscoëfficiënt op dat deel, en o — nieuw werk voor gegevensvoorbereiding, verduidelijkende vragen en controle van het resultaat.

Hieronder staat een gekalibreerd voorbeeld specifiek voor dit basisscenario. Het doel is niet om een universele norm te bewijzen, maar om te laten zien hoe hetzelfde model de cijfers uit de tabel voor één concreet geval kan reproduceren. In een echt team kun je zulke parameters beter kalibreren op de laatste 3–5 Backlog Refinements en vervolgens je eigen bereik krijgen.

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))

Rol	Zonder AI	Met AI (rekening houdend met nieuw werk)	Wat verandert
Product Owner	4,5 u	2,5 u	Verzamelt sneller de klantcontext, maar besteedt een deel van de tijd aan het voorbereiden van de input en verduidelijkende vragen
Businessanalist	10 u	5 u	Minder handmatig zoeken en herschrijven, meer verificatie, redactie en controle dat AI niets belangrijks heeft gemist
Backend-ontwikkelaar	3,5 u	2 u	Krijgt sneller een eerste technische analyse, maar controleert apart de architectuurbeperkingen en het risico op duplicaten
Frontend-ontwikkelaar	3 u	1,5 u	Schat sneller de UI-inbouw en instellingen in, maar raakt eerder betrokken bij de controle van betwiste punten
Kwaliteitsingenieur / QA-ingenieur	3 u	2 u	Krijgt eerder grensgevallen en tijdelijke risico’s, maar raakt sterker betrokken bij de controle van hiaten en negatieve scenario’s
UX/UI-designer	3 u	2 u	Verzamelt sneller een eerste variant van de UI-aanpak en sluit vooraf overbodige interfacevarianten uit
Scrum Master	2,5 u	1,5 u	Minder tijd voor organisatorische afstemming van context, meer voor het faciliteren van beslissingen en het vastleggen van open vragen
Totaal	29,5 u	16,5 u	Scenariovoordeel — ongeveer 13 mensuren op één zo’n Backlog Refinement, al na verrekening van het basale nieuwe werk

Scenariobereik: hoe het voordeel kan variëren

Scenario	Zonder AI	Met AI	Netto voordeel	Wanneer dat gebeurt
Voorzichtig	24–28 u	18–21 u	4–10 u	Bronnen zijn onvolledig, veel handmatige controle, het team bouwt pas sjablonen voor werken met AI op.
Basis	28–32 u	15–18 u	10–15 u	Ongeveer zo ziet het gemodelleerde geval eruit: AI versnelt de voorbereiding goed, maar het nieuwe werk voor verificatie is al meegenomen.
Sterk	30–36 u	14–17 u	13–19 u	Het team heeft goede bronnen, herhaalbare sjablonen en duidelijke regels voor datagebruik en handmatige controle.

Welk nieuw werk al is meegenomen in het scenario met AI

De tabel hieronder doet het eindvoordeel uit de eerste niet teniet. Ze licht alleen toe door welke nieuwe acties een deel van de bespaarde tijd terug in het proces vloeit — en waarom het netto-effect daarna nog steeds merkbaar blijft.

Nieuw werkgebied	Wat er met AI bijkomt	Waarom dit nodig is
Voorbereiding van invoergegevens	Opschonen, anonimiseren, samenvatten van de relevante context	Om het model niet met rommel te overbelasten en geen overbodige gegevens mee te slepen
Verduidelijkende vragen	Herhaalde runs, afbakening van het antwoord, verzoek om feiten en aannames te scheiden	Om het eerste mooie antwoord niet voor definitief begrip aan te zien
Instellen van sjablonen	Prompts, sjablonen voor user stories, regels voor het formaat van het resultaat	Zodat AI een bruikbare, herhaalbare draft levert en geen willekeurige tekst
Feitencontrole	Controle van bronverwijzingen, termen, statussen en beperkingen	Om hallucinaties van het model en valse duidelijkheid vóór de meeting op te vangen
Documenteren van vertrouwen	Vastleggen wat precies handmatig is gecontroleerd en waarom het resultaat betrouwbaar is	Zodat het team verantwoordelijkheid niet vervangt door een mooie draft

Verschillen per fase

Fase	Zonder AI	Met AI
Context verzamelen voor de meeting	Langdurig handmatig zoeken in documenten, tickets en kennis van mensen	Een eerste pass over de bronnen en een korte samenvatting gaan merkbaar sneller
Draft van de user story	Wordt handmatig geschreven en blijft vaak ruw	Er is een sterke basis die het team kan bekritiseren en aanscherpen
De Backlog Refinement zelf	Veel tijd gaat naar het gelijk trekken van begrip	De focus verschuift naar betwiste beslissingen, afhankelijkheden en de grenzen van de eerste versie
Nawerk na de meeting	Vaak moet de user story bijna helemaal opnieuw worden geschreven	De uitkomsten zijn al goed verpakt en vragen minder handmatige nabewerking

Kwaliteitschecklist voor AI-voorbereiding op refinement

Belangrijk: deze Definition of Ready is een interne praktijk van het team, geen onderdeel van de Scrum Guide. Hier dient hij als bescherming tegen valse duidelijkheid, hiaten en vage verantwoordelijkheid in AI-voorbereiding.

Definition of Ready voor een AI-draft

Feiten zijn gescheiden van aannames: het team begrijpt wat uit bronnen komt en wat door het model is voorgesteld.

Er zijn links of duidelijke verwijzingen naar bronnen voor de belangrijkste product- en technische beweringen.

Open vragen zijn niet verstopt onder nette tekst, maar expliciet benoemd.

Domeintermen, statussen, beperkingen, rollen en afhankelijkheden zijn gecontroleerd.

Voor elke kernbewering is het niveau van onderbouwing duidelijk: een feit uit een bron, een werkhypothese of een aanname van het model.

Grensgevallen, negatieve scenario's en tijdelijke risico's zijn apart gecontroleerd.

Het is duidelijk welke data niet aan het model mocht worden gegeven en welke maatregelen voor datahygiëne zijn toegepast.

Er zijn eigenaren voor verificatie aangewezen per type bewering: bedrijfslogica, architectonische haalbaarheid, testbaarheid en omgang met data.

Het team is het erover eens dat een AI-draft grondstof voor discussie is, niet een bijna kant-en-klare taak.

Om deze checklist niet te abstract te laten blijven, zo zou hij eruitzien in ons geval met e-mailherinneringen:

AI stelt voor om de statussen not_started, in_progress en expired op te nemen — het team markeert expliciet dat expired voorlopig een hypothese blijft en geen bevestigde regel voor de eerste versie.
In de korte samenvatting staat dat meldingen moeten worden verzonden op basis van de tijdzone van de gebruiker — de backend controleert dit tegen de bronnen en bevestigt dat in het huidige systeem de tijdzone alleen op klantniveau wordt opgeslagen, en dat overgangen tussen tijdzones en DST apart moeten worden gecontroleerd.
AI voegde de verzendgeschiedenis toe als een "vanzelfsprekend" onderdeel van de oplossing — de Product Owner en BA beslissen apart of dit een verplicht onderdeel van de eerste versie is of een verbetering voor de volgende release, omdat hier ook een kwestie van audit en belasting van de support speelt.
QA krijgt niet alleen een lijst met grensgevallen, maar een concrete opdracht om duplicaten te controleren bij herhaald starten van schedulertaken, fallback-scenario's voor talen, uitzonderingen voor gearchiveerde en gedeactiveerde gebruikers en negatieve scenario's rond deadlines.
Backend controleert apart rate limits, throttling, deliverability en hoe het systeem zich gedraagt bij herhaalde verzendingen en fouten van de provider.
PO en BA valideren daarnaast het notificatiebeleid: aan wie herinneringen mogen worden gestuurd, waar opt-out of klantuitzonderingen nodig zijn, en wat als acceptabel gedrag geldt voor verplichte cursussen.

Voor zo'n geval is het nuttig om ook twee praktische zaken apart te bespreken die vaak pas dichter bij productie opduiken: deliverability wordt snel een belasting voor support en het klantondersteuningsteam als er geen goede diagnose is voor "waarom is de e-mail niet aangekomen", en quiet hours en kalendervensters blijken vaak geen "extra optie" maar een zakelijke eis van de klant.

Wie wat handmatig controleert

Wat we controleren	Wie is eigenaar	Voorbeeld in de LMS-case
Doel en productbeleid	PO en BA	Aan wie en wanneer herinneringen worden gestuurd, welke uitzonderingen toegestaan zijn, waar de grenzen van de eerste versie liggen.
Correctheid van regels en statussen	BA	Welke statussen gelden als "niet afgerond", wat te doen met `expired` en waar dit al door bronnen is bevestigd.
Architectonische beperkingen	Backend-ontwikkelaar	Deduplicatie, schedulertaken, idempotentie, auditlog, rate limits en gedrag bij herhaalde verzendingen.
UI-grenzen van de eerste versie	Frontend-ontwikkelaar en UX/UI-ontwerper	Waar de instellingen staan, of een apart geschiedenisscherm nodig is en welke interfacescenario's daadwerkelijk in de eerste versie zitten.
Negatieve en tijdelijke scenario's	Kwaliteitsingenieur / QA-ingenieur	DST, tijdzones, fallback-scenario's voor talen, uitzonderingen voor gearchiveerde en gedeactiveerde gebruikers, en duplicaten bij herhaald starten van schedulertaken.
Faciliteren van beslissingen en open vragen	Scrum Master	Wat al is besloten, wat betwist blijft en waar het team een bewust compromis moet sluiten.
Datahygiëne en toelaatbaarheid van data	PO/BA en, indien aanwezig, Security of DPO	Wat aan het model mag worden gegeven, wat geanonimiseerd moet worden en welke controles verplicht zijn voordat AI-voorbereiding start.

Wat ik het team zou aanraden

Een AI-draft niet als een afgeronde taak beschouwen alleen omdat hij er goed uitziet.
Expliciet afspreken welke delen van de context het team vóór de meeting handmatig moet controleren en welke pas tijdens de meeting zelf.
Geleidelijk eigen product- en procespatronen naar de team-AI-laag verplaatsen in plaats van alleen een algemene chat 'as is' te gebruiken.
Refinement niet mechanisch inkorten alleen omdat de voorbereiding sneller is geworden.
Bewust beslissen waar de vrijgekomen tijd naartoe gaat: naar kwaliteit, leren, documentatie, technische schuld of het herstellen van de aandacht van het team.

Daarnaast is het belangrijk om de grenzen van de toepasbaarheid van dit scenario in gedachten te houden. Het AI-effect zal sterk verschillen afhankelijk van de volwassenheid van de documentatie, de beschikbaarheid van interne bronnen, de domeincomplexiteit van het product en de mate waarin het team impliciete kennis kan omzetten in herhaalbare context. Waar de brongegevens zwak zijn, kan AI de verpakking versnellen, maar niet noodzakelijk de kwaliteit van beslissingen verbeteren.

Conclusie

Heel kort samengevat zou ik het belangrijkste AI-effect voor refinement zo formuleren: AI versnelt niet de afspraak van het team zelf, maar de voorbereiding van het materiaal daarop. Daarom wordt refinement sneller aan de voorkant: sneller wordt context verzameld, sneller verschijnt een concept, sneller worden basisvragen en risico's zichtbaar, sneller worden de resultaten verpakt.

Maar dat maakt refinement niet automatisch eenvoudiger. Want zodra de kosten van voorbereiding dalen, neemt de waarde toe van wat AI nog niet echt goed kan: het domein begrijpen, echte beperkingen aanvoelen, valse helderheid opmerken, zorgvuldig met gegevens omgaan en het team helpen bewuste compromissen te sluiten.

Daarom is de beste manier om naar AI in refinement te kijken deze: het haalt een deel van het dure handwerk rond de praktijk weg, maar maakt de menselijke controle van de betekenis nog belangrijker. Hoe eenvoudiger het werd om backlogitems te produceren, hoe belangrijker het werd om te begrijpen welke ervan echt klaar zijn voor bespreking en welke er alleen maar goed uitzien. In de volgende artikelen van de serie is het interessant om te zien hoe deze verschuiving niet alleen het proces beïnvloedt, maar ook de cultuur van het gebruik van teamtijd.

Bronnen en richtlijnen

← Alle essays