Grooming van taken in mobiele ontwikkeling: essentie, doelen en uitvoeringsproces

Wat is grooming van taken?

Backlog Grooming (refinement) — het proces van het voorbereiden van Product Backlog taken voor toekomstige sprints. Een bijeenkomst waarin de Product Owner en het ontwikkelingsteam taken doorlopen: vereisten verduidelijken, Acceptance Criteria toevoegen, complexiteit beoordelen, afhankelijkheden en risico's identificeren. In de Scrum Guide bestaat geen verplichte „grooming" gebeurtenis — het is een aanvullende praktijk die Scrum-teams introduceren om onzekerheid tijdens Sprint Planning te verminderen. Aanbevolen frequentie — 1 keer per sprint, maximaal 60 minuten.

De term „opruimen" (grooming) weerspiegelt de essentie: het team „ruimt" de backlog op, verwijdert verouderde taken, verduidelijkt onduidelijke en splitst te grote. In mobiele ontwikkeling is grooming vooral belangrijk vanwege platformspecifieke kenmerken: een taak voor Android kan qua complexiteit verschillen van de iOS-versie, targetSdk, compileSdk en compatibiliteit met API-niveaus moeten worden overwogen. Zonder grooming wordt Sprint Planning chaos: het team ziet taken voor het eerst en kan ze niet schatten, wat leidt tot onvoorspelbaarheid en vertragingen.

Het resultaat van grooming — enkele taken klaar voor Sprint Planning: ze hebben een beschrijving, Acceptance Criteria, schatting en voldoen aan Definition of Ready. De Product Owner moet taken in prioriteitsvolgorde groomen: het dichtst bij de huidige sprint — het meest gedetailleerd. Taken voor 3-4 sprints vooruit — alleen op epic-niveau. Progressive Refinement techniek: hoe dichter de taak bij de sprint, hoe gedetailleerder de beschrijving. Voor taken in de huidige sprint — full refinement (AC, ontwerp, API-specificatie). Voor taken over 2 sprints — story-level (user story zonder implementatiedetails). Voor taken over 3+ sprints — epic-level (alleen naam en businesswaarde).

Definition of Ready: wanneer is een taak klaar voor de sprint

Definition of Ready (DoR) — checklist met criteria waaraan een taak moet voldoen voordat deze wordt opgenomen in de Sprint Backlog. DoR is een contract tussen de Product Owner en het team: PO garandeert dat alle informatie voor ontwikkeling beschikbaar is, het team garandeert dat het de taak kan schatten en uitvoeren. DoR is niet universeel — elk team bepaalt zijn eigen set criteria. Zonder DoR kan een taak met onduidelijke vereisten in de sprint terechtkomen, wat leidt tot herbewerking en vertragingen.

Typische DoR voor mobiele ontwikkeling: 1) Acceptance Criteria zijn beschreven (acceptatiecriteria in Given-When-Then formaat). 2) Ontwerplayout is klaar in Figma (voor UI-taken) met alle statussen: default, loading, error, empty state. 3) API-specificatie is goedgekeurd (OpenAPI/Swagger, voorbeelden van verzoeken en antwoorden). 4) Schatting in story points is aanwezig. 5) Afhankelijkheden van andere taken zijn geïdentificeerd. 6) Taak is niet afhankelijk van onvoltooide externe componenten. 7) Mobiele specificatie: doel-OS-versies, noodzaak van feature flag, ondersteuning voor oude API-niveaus zijn bepaald.

Schattingstechnieken voor taken

Planning Poker — de populairste schattingstechniek tijdens grooming. Elke ontwikkelaar krijgt een set kaarten met Fibonacci-getallen (1, 2, 3, 5, 8, 13, 21). PO toont de taak en legt deze uit. Na discussie tonen alle tegelijkertijd hun kaart. Als schattingen sterk verschillen (bijv. 3 en 13) — ontwikkelaars leggen hun schatting uit, waarna ze opnieuw stemmen. Iteraties worden herhaald tot consensus. Het doel van Planning Poker is niet exacte schatting, maar het identificeren van verschillen in taakbegrip.

T-Shirt Sizing — een vereenvoudigde techniek voor snelle schatting: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Geschikt voor initiële backlog-sortering wanneer er veel taken zijn en snel de grootteorde moet worden geschat. Na T-Shirt Sizing wordt een nauwkeurigere schatting uitgevoerd via Planning Poker voor taken van de volgende sprint. Affinity Estimation — groepsgewijs sorteren van taken op relatieve complexiteit zonder getallen; taken worden op tafel gelegd van eenvoudigst naar meest complex, vervolgens gegroepeerd in clusters, elk cluster krijgt een schatting.

In mobiele ontwikkeling moet de schatting rekening houden met platformcomplexiteit. Een Android-taak kan worden geschat op 5 SP, en dezelfde taak voor iOS — op 3 SP (of omgekeerd). Dit is normaal: verschillende platforms hebben verschillende implementatiecomplexiteit. Tip: schat elk platform afzonderlijk als het team cross-platform is. Gebruik een relatieve schaal: basistaak (bijv. een scherm met tekst en knop) = 1 SP. Al het andere — relatief daaraan. Volgens Scrum.org (2025) bereikt de schattingsnauwkeurigheid van het team na 3-4 sprints ±20% van de werkelijke complexiteit.

Decompositie: hoe grote taken op te delen

Taken groter dan 8 SP moeten worden gedecomposeerd in kleinere. Grote taken kunnen niet in één sprint worden voltooid, zijn moeilijk te schatten en geven geen gevoel van vooruitgang. Decompositietechniek: verdeel de taak over horizontale lagen (UI → ViewModel → Repository → Network/DB) of over verticale doorsneden (feature: één volledig scherm). Horizontale decompositie is geschikter voor mobiele ontwikkeling: Sub-task 1 — UI-layout (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Unittests.

Verticale decompositie — het snijden van een user story in kleinere verhalen met onafhankelijke waarde. Voorbeeld: Epic „Winkelwagen" → Story 1 „Product toevoegen aan winkelwagen", Story 2 „Winkelwagen weergeven", Story 3 „Product verwijderen uit winkelwagen", Story 4 „Bestelling plaatsen". Elke Story heeft zijn eigen businesswaarde en kan onafhankelijk worden uitgebracht. SPoK (Story Points on Kano): rangschik Stories op businesswaarde (Must-have, Should-have, Could-have) en implementeer in volgorde van waarde.

Checklist voor decompositie tijdens grooming: 1) Taak groter dan 8 SP? → Decomponeren. 2) Zijn er Acceptance Criteria? → Zo niet — toevoegen. 3) Afhankelijk van andere taken? → Afhankelijkheden identificeren en vastleggen. 4) Bevat onzekerheid? → Spike (onderzoek) toevoegen vóór de hoofdtaak. 5) Ontwerp nodig? → Controleer gereedheid van layouts. INVEST-regel: Independent (onafhankelijk van anderen), Negotiable (bespreekbaar), Valuable (waardevol voor business), Estimable (schatbaar), Small (klein), Testable (testbaar). Als een taak niet voldoet aan INVEST — is deze niet klaar voor de sprint.

Het groomingproces: stap voor stap

Stap 1: Opwarmen (5 minuten). Scrum Master herinnert aan het doel van grooming en DoR. Het team kijkt naar het bord, PO toont welke taken zullen worden besproken. Stap 2: Taakbeoordeling (30 minuten). PO presenteert achtereenvolgens taken van het einde van de huidige en het begin van de volgende sprint. Voor elke taak: naam, beschrijving, Acceptance Criteria (indien aanwezig), link naar ontwerp, API-specificatie. Het team stelt verhelderende vragen: „Is er een layout voor de lege status?", „Welke HTTP-methode?", „Wat is de iOS minimum deployment target?".

Stap 3: Schatting (15 minuten). Het team schat de taak via Planning Poker of T-Shirt Sizing. Als het verschil > 2 SP is — bespreken ze de oorzaken en stemmen opnieuw. Regel: als een taak niet kan worden geschat (onduidelijke vereisten, geen ontwerp) — wordt deze teruggestuurd naar PO voor herziening en komt met verduidelijkingen naar de volgende grooming. Schat geen taken met onbekenden — dit leidt gegarandeerd tot fouten in de sprint. Stap 4: Resultaten vastleggen (10 minuten). PO registreert schattingen in Jira/Linear, werkt de taakbeschrijving bij en stelt prioriteiten.

Resultaten van grooming: 3-7 volledig voor Sprint Planning gereed zijnde taken (met DoR, schatting, ontwerp, API). PO werkt de backlog bij: verwijdert verouderde taken, voegt duplicaten samen, verduidelijkt prioriteiten. Belangrijk: grooming beëindigt het werk van PO niet — tussen grooming-sessies moet hij volgende taken voorbereiden. Aanbevolen tempo: PO bereidt 3-4 taken voor voor grooming, het team verwerkt ze. Als er meer dan 50 taken in de backlog zijn — moet PO prioritering (MoSCoW of Weighted Shortest Job First) uitvoeren vóór grooming.

Hoe grooming verschilt van Sprint Planning

Grooming — is voorbereiding. Er zijn geen verplichtingen — de taak wordt alleen verduidelijkt en geschat. Sprint Planning — is een verplichting. Het team selecteert taken uit de tijdens grooming voorbereide pool en neemt de verplichting op zich om ze in de sprint uit te voeren. Belangrijkste verschillen: grooming is niet gebonden aan een specifieke sprint (algehele backlog refinement), tijdens grooming is er geen Sprint Goal, grooming kan op elk moment tijdens de sprint plaatsvinden. Sprint Planning — strikt aan het begin van de sprint en leidt altijd tot een Sprint Goal.

Tijdens grooming worden taken alleen geschat, maar niet in de sprint opgenomen. Tijdens Planning worden taken geselecteerd uit de voorbereide pool. Zonder grooming duurt Sprint Planning 6-8 uur (in plaats van 4), omdat het team taken voor het eerst ziet en ze niet snel kan schatten. 80/20-regel: 80% van de taken tijdens Sprint Planning moeten volledig gereed zijn (door grooming), 20% — kunnen nieuw zijn (urgente bugs, hotfixes). Als er tijdens Planning meer dan 20% ongeschatte taken zijn — was grooming onvoldoende.

Veelvoorkomende fouten bij grooming

Fout 1: grooming één keer per maand. Het team verzamelt 3-4 sprints aan taken, probeert alles in 2 uur te verduidelijken. Resultaat: de helft van de taken blijft ongeschat, Planning duurt de hele dag. Oplossing: grooming moet regelmatig zijn — 1 keer per sprint, 60 minuten. Als er veel taken zijn — voeg een tweede grooming midden in de sprint toe. Beter minder taken kwalitatief groomen dan veel — maar oppervlakkig. Tempo: 3-5 taken per grooming, elk krijgt volledige discussie en schatting.

Fout 2: schatting zonder context. PO toont de taak „Winkelwagen scherm implementeren" zonder ontwerp, zonder API, zonder AC. Het team schat „op het oog" — 13 SP. Tijdens Planning blijkt dat het eigenlijk 5 SP is (omdat het scherm eenvoudig is). Oplossing: de taak wordt niet geschat als er geen ontwerp of API is. PO is verplicht materialen vóór grooming voor te bereiden. Regel: „Geen layout — geen schatting". Uitzondering: Spike-taken — onderzoek van onzekerheid, worden apart zonder ontwerp geschat (2-5 SP afhankelijk van onderzoekscomplexiteit).

Fout 3: grooming verandert in Planning. Het team begint taken aan uitvoerders toe te wijzen en te bespreken wie wat gaat doen. Oplossing: eraan herinneren dat grooming voor verduidelijking is, niet voor toewijzing. Toewijzing — tijdens Daily na start van de sprint. Grooming beantwoordt de vraag „wat doen we?", Planning — „wanneer doen we?", Daily — „wie doet het?". Het mengen van deze vragen in één bijeenkomst vermindert de effectiviteit van elk. Scrum Master moet de Planning-discussie stoppen en de focus verleggen naar taakverduidelijking.

Fout 4: negeren van Tech Debt. Tijdens grooming worden alleen nieuwe functies besproken, technische taken worden genegeerd. Na 3-4 sprints hoopt technische schuld zich op tot een kritiek niveau. Oplossing: bij elke grooming moet ten minste 1 Tech-taak worden geschat. Verhouding: op 3 features → 1 technische taak. Gebruik de Tech Debt Ratio-metriek: verhouding van Tech-taken tot Feature-taken in de sprint. Doelwaarde: 0.25-0.3 (25-30% van de tijd aan technische schuld). Als de ratio onder 0.2 is — zal de ontwikkelsnelheid in volgende sprints dalen.