Scrum4Me/docs/Ideas/ai-driven-scrum-planning-research.md

---
title: "Onderzoek — AI-gedreven programmeren en Scrum planning"
status: draft
audience: [product, ai-agent]
language: nl
last_updated: 2026-05-11
---

# Onderzoek — AI-gedreven programmeren en Scrum planning

## Vraag

Wat is het effect van AI-assisted / AI-driven programming op de manier waarop we Scrum toepassen, als werk niet meer in 1-2 weekse sprints hoeft te worden gepland maar in meerdere uitvoercycli per dag kan worden gerealiseerd? Wat gebeurt er met burndown, velocity en planning als tokengebruik, verificatie en agent-efficiency belangrijker worden?

## Korte conclusie

AI maakt Scrum niet overbodig, maar verandert waar Scrum op moet sturen.

Traditionele sprintplanning gebruikt vaak velocity/story points als proxy voor menselijke uitvoercapaciteit. In AI-gedreven ontwikkeling wordt menselijke typ-/bouwtijd veel minder voorspelbaar als bottleneck. De nieuwe bottlenecks zijn:

- helderheid van productbeslissingen;
- kwaliteit van backlog-items en acceptatiecriteria;
- beschikbare context voor agents;
- verificatiecapaciteit: tests, review, security, deploy;
- tokenkosten en modelkeuze;
- rework door foutieve of half-passende AI-output.

Daarom moet planning verschuiven van "hoeveel story points kunnen we in twee weken doen?" naar "welke waardevolle hypothese kunnen we nu veilig laten uitvoeren, verifieren en leren, binnen een token- en reviewbudget?"

## Wat de bronnen laten zien

### 1. Het empirische bewijs is gemengd

Onderzoek naar Copilot liet in een gecontroleerde programmeertaak zien dat deelnemers met Copilot de taak 55,8% sneller voltooiden. Een latere Microsoft-studie met drie field experiments bij 4.867 developers vond gemiddeld 26,08% meer voltooide taken bij developers met AI-code-completion.

Tegelijk vond METR in 2025 in een realistische RCT met ervaren open-source developers dat AI-tools taken juist 19% langzamer maakten. De taken waren echte issues in grote codebases die developers goed kenden. METR waarschuwt zelf tegen te brede generalisatie, maar het resultaat is belangrijk: AI-snelheid hangt sterk af van taaktype, codebase-context, kwaliteitslat en meetmethode. In 2026 gaf METR bovendien aan dat het meten van AI-uplift lastiger wordt doordat developers liever niet meer zonder AI werken en doordat sommige developers meerdere agents tegelijk gebruiken.

Implicatie: Scrum4Me moet geen vaste productiviteitsfactor aannemen. Meet per product, per agent-run en per taaktype.

### 2. DORA: AI is een versterker, geen oplossing

DORA 2025 concludeert dat AI vooral een amplifier is: het versterkt bestaande sterke en zwakke punten. Google rapporteert bijna universele adoptie, veel ervaren individuele productiviteitswinst, maar ook een vertrouwensparadox en complexere effecten op organisatorische performance.

DORA's AI Capabilities Model noemt zeven randvoorwaarden die AI-effecten versterken:

- duidelijke AI-stance/policy;
- gezonde data-ecosystemen;
- AI-toegankelijke interne data;
- sterke version-control-praktijken;
- kleine batches;
- user-centric focus;
- kwalitatieve interne platforms.

Voor Scrum betekent dit: de sprint moet niet groter worden omdat agents sneller code schrijven. De batch moet kleiner worden, met scherpere feedback.

### 3. Agile verschuift naar outcome- en governance-gedreven planning

Digital.ai's 18th State of Agile beschrijft AI als een verschuiving van ondersteunende tool naar orchestrator van de delivery lifecycle. Tegelijk noemt het rapport hogere ROI-druk, governance-lag en de noodzaak om Agile-investeringen aan meetbare business outcomes te koppelen.

Implicatie: velocity en burndown zijn onvoldoende als hoofdmetrics. Ze laten activiteit zien, geen waarde, geen kosten en geen risico.

### 4. Tokengebruik wordt economisch relevant, maar is geen doel op zichzelf

Stanford Digital Economy Lab vond in 2026 dat agentic coding tasks veel token-intensiever zijn dan code chat/reasoning, dat inputtokens de kosten domineren, dat runs op dezelfde taak tot 30x kunnen verschillen in tokengebruik, en dat meer tokens niet automatisch meer accuracy opleveren.

Jellyfish analyseerde 12.000 developers bij 200 bedrijven en vond dat meer tokengebruik wel met meer output correleert, maar disproportioneel duurder wordt. De topgebruikers haalden ongeveer twee keer zoveel PR-throughput, maar met ongeveer tien keer zoveel tokens per PR.

Implicatie: tokenusage is een cost/efficiency-signaal, geen prestatiebadge. "Tokenmaxxing" is net zo gevaarlijk als velocity maximaliseren.

## Wat verandert aan Scrum?

### Sprint

De Sprint blijft nuttig als container voor focus, inspectie en adaptatie. Maar bij AI-gedreven werk is een sprint minder een capaciteitsmandje voor menselijke arbeid en meer een beslis- en leerhorizon.

Advies:

- Gebruik "Sprint" voor productfocus en Sprint Goal.
- Gebruik "AI runs" of "execution cycles" binnen de sprint voor 1-4 uitvoercycli per dag.
- Noem 4 cycli per dag liever geen 4 Scrum-sprints, tenzij je ook echt 4 keer Sprint Planning, Review en Retrospective wilt doen. Dat levert ceremonie-overhead op.

### Sprint Planning

Planning verschuift van effort forecast naar control loop.

Oude vraag:

- Hoeveel werk kunnen we deze sprint doen?

Nieuwe vraag:

- Welke waardevolle slice is klaar voor agent-uitvoering?
- Welke context en tests maken het veilig?
- Welk model/mode/budget past bij risico en complexiteit?
- Hoe weten we binnen 30-120 minuten of dit goed genoeg is?
- Wat is de maximale token- en reviewspend voor deze poging?

### Daily Scrum

Daily Scrum wordt minder statusmeeting en meer flow-control:

- Welke agent-runs zijn afgerond, geblokkeerd of failed?
- Waar zit de verificatiequeue?
- Welke Product Owner-beslissing ontbreekt?
- Welke context ontbreekt waardoor tokens of rework oplopen?
- Moeten we scope heronderhandelen zonder het Sprint Goal te beschadigen?

Bij 4 runs per dag kan een korte "run review" na elke run de Daily Scrum deels vervangen.

### Sprint Review

Review wordt frequenter en meer outcome-gericht:

- Wat is echt geaccepteerd en bruikbaar?
- Welke hypothese is gevalideerd?
- Wat is alleen code-output maar nog geen waarde?
- Welke user feedback of runtime data hebben we?

### Retrospective

Retrospective moet expliciet AI-systemen verbeteren:

- Welke prompts, contextbestanden of specs verminderden rework?
- Welke modelkeuzes waren te duur of te zwak?
- Waar faalden tests/reviews te laat?
- Welke taken waren slecht voorbereid voor agents?
- Waar waren menselijke beslissingen de bottleneck?

## Nieuwe planningshiërarchie

Een praktisch model voor Scrum4Me:

| Laag | Cadans | Doel | Output |
|---|---:|---|---|
| Product Goal / roadmap | weken-maanden | richting en waarde | product outcomes, prioriteiten |
| Sprint | 1 dag tot 1 week | focus en leerdoel | Sprint Goal, selected PBIs/stories, budget |
| AI execution run | 1-3 uur | concrete slice bouwen/verifieren | PR/diff, testresultaat, token/cost telemetry |
| Agent job | minuten-uren | taak uitvoeren | logs, patch, status, vragen |

Voor solo/kleine teams met Scrum4Me is een dag-sprint of week-sprint met meerdere AI runs realistischer dan 4 volledige Scrum-sprints per dag.

## Nieuwe metrics

### Behoud, maar herinterpreteer

- Lead time: idee/story -> geaccepteerde productie-wijziging.
- Cycle time: taak/run start -> done.
- Deployment frequency.
- Change failure rate.
- MTTR.
- Escaped defects.

Deze blijven belangrijker dan velocity.

### Vervang velocity als hoofdmetric

Velocity/story points kunnen nog gespreksmateriaal zijn voor complexiteit en onzekerheid, maar niet meer als centrale capaciteitsmetric.

Betere hoofdmetrics:

- accepted increments per dag/week;
- validated outcomes per week;
- lead time per PBI/story;
- verification queue time;
- change failure rate na AI-runs;
- rework rate na review;
- human intervention rate;
- agent first-pass success rate.

### Voeg token-economie toe

Nuttige tokenmetrics:

- tokens per accepted task;
- tokens per merged PR;
- tokens per validated outcome;
- tokens per failed/abandoned run;
- input/output/cache-token mix;
- cost per accepted task;
- cost per defect fixed;
- review minutes per 1M tokens;
- token spend by model/mode/job-kind;
- wasted tokens: output niet gebruikt, failed loops, repeated context discovery.

Belangrijke waarschuwing: tokens zijn een input-cost, geen output-value. Gebruik ze als budget en efficiency-signaal, niet als score.

### Nieuwe samengestelde metric

Voor Scrum4Me zou een nuttige metric kunnen zijn:

```text
AI Delivery Efficiency =
  accepted value units
  / (token cost + human review time + elapsed time + rework penalty)
```

In de praktijk kan dit simpeler:

```text
accepted_tasks_per_euro
accepted_tasks_per_1M_tokens
merged_PRs_per_review_hour
validated_outcomes_per_day
```

## Definition of Ready voor AI

Een story/task is AI-ready als:

- het gewenste gedrag concreet is;
- acceptatiecriteria testbaar zijn;
- relevante files, patronen en docs bekend of vindbaar zijn;
- non-goals en scopegrenzen expliciet zijn;
- risico duidelijk is: laag/middel/hoog;
- vereiste verificatie bekend is;
- tokenbudget/model/mode is gekozen;
- open productvragen zijn beantwoord of expliciet buiten scope gezet.

## Definition of Done voor AI

Done betekent niet "agent heeft code geschreven". Done betekent:

- diff/PR is geaccepteerd;
- tests/lint/typecheck/build passend bij risico zijn groen;
- security/privacy/demo-mode checks zijn gedaan waar relevant;
- menselijke review is gedaan voor risicovolle of user-facing wijzigingen;
- tokenusage/cost is gelogd;
- rework/lessons zijn teruggekoppeld naar prompt, docs of backlog;
- productwaarde is zichtbaar of meetbaar.

## Voorstel voor Scrum4Me planning

### 1. Sprint als focuscontainer

Maak een sprint niet langer primair een verzameling werk voor 1-2 weken, maar een focuscontainer:

- Sprint Goal;
- geselecteerde PBI's/stories;
- AI-run budget;
- verificatie-WIP-limiet;
- risico-policy.

### 2. AI Runs binnen de sprint

Voeg of gebruik een concept als `SprintRun`:

- `PLANNED -> RUNNING -> VERIFYING -> ACCEPTED | REWORK | FAILED | ABANDONED`
- gekoppelde `ClaudeJob`s / agent jobs;
- model/mode snapshot;
- tokenbudget en werkelijk tokengebruik;
- affected stories/tasks;
- testresultaat;
- reviewbeslissing.

### 3. Planningproces per run

1. Selecteer een kleine slice uit de Sprint Backlog.
2. Controleer AI-ready criteria.
3. Kies model/mode/tokenbudget.
4. Start agent jobs.
5. Verzamel patch, logs, testresultaten en tokenusage.
6. Verifieer.
7. Accepteer, stuur terug voor rework, of stop de run.
8. Update backlog en metrics.

### 4. Dashboard-shift

Vervang klassieke burndown als primaire grafiek door:

- token burnup vs accepted outcomes;
- verification queue;
- accepted/rework/failed runs;
- lead time distribution;
- cost per accepted task;
- change failure / rollback rate;
- remaining uncertainty per Sprint Goal.

Burndown kan blijven als "remaining selected stories/tasks", maar niet als performance-meter.

## Productimplicaties voor Scrum4Me

1. Voeg token/cost telemetry toe aan `ClaudeJob` en `SprintRun`.
2. Maak AI-run planning zichtbaar op de Sprint-pagina.
3. Voeg `AI Ready` checks toe aan story/task dialogs of een planning pane.
4. Maak verification WIP expliciet: niet meer agents starten dan je kunt verifieren.
5. Voeg budgetrails toe: per sprint, per run, per task, per model.
6. Rapporteer tokenusage altijd naast outcome: token-only dashboards sturen verkeerd gedrag.
7. Maak retrospectives data-driven: prompt/context/model/test-strategie verbeteren.

## Bronnen

- Scrum Guide 2020 — Sprint Planning, Sprint Backlog, Sprint Goal: https://scrumguides.org/scrum-guide.html
- Microsoft Research — GitHub Copilot controlled experiment: https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/
- Microsoft Research — three field experiments, 4.867 developers: https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/
- METR 2025 — experienced open-source developer RCT: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR 2026 — measurement redesign and concurrent-agent measurement issues: https://metr.org/blog/2026-02-24-uplift-update/
- DORA 2025 — State of AI-assisted Software Development: https://dora.dev/research/2025/dora-report/
- Google Research publication page for DORA 2025: https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/
- Google Cloud — DORA AI Capabilities Model: https://cloud.google.com/blog/products/ai-machine-learning/introducing-doras-inaugural-ai-capabilities-model/
- Google blog summary of DORA 2025: https://blog.google/innovation-and-ai/technology/developers-tools/dora-report-2025/
- Digital.ai — 18th State of Agile press release: https://digital.ai/press-releases/digital-ais-18th-state-of-agile-report-marks-the-start-of-the-fourth-wave-of-software-delivery/
- Stanford Digital Economy Lab — token consumption in agentic coding tasks: https://digitaleconomy.stanford.edu/publication/how-do-ai-agents-spend-your-money-analyzing-and-predicting-token-consumption-in-agentic-coding-tasks/
- GitHub Docs — Copilot usage metrics: https://docs.github.com/en/enterprise-cloud@latest/copilot/reference/copilot-usage-metrics/copilot-usage-metrics
- Jellyfish — tokenmaxxing and token ROI analysis: https://jellyfish.co/blog/is-tokenmaxxing-cost-effective-new-data-from-jellyfish-explains/
- Microsoft Research — LLM metric framework and token utilization: https://www.microsoft.com/en-us/research/articles/how-to-evaluate-llms-a-complete-metric-framework/