Sprint in mobiele ontwikkeling: essentie, duur en planning

Wat is een sprint in ontwikkeling?

Sprint — een tijdsinterval (timebox) met een vaste duur waarna het team een gebruiksklaar productincrement oplevert. Het sprintconcept vormt de basis van Scrum, maar wordt ook in andere Agile-frameworks gebruikt. In mobiele ontwikkeling is het increment een build van de app die op een apparaat kan worden geïnstalleerd, getest en aan stakeholders getoond. Een sprint kan niet worden verlengd — als taken niet zijn voltooid, worden ze overgedragen naar de volgende sprint.

Het belangrijkste kenmerk van een sprint is de vaste duur. Het team wijzigt het sprintdoel niet na goedkeuring. Dit geeft voorspelbaarheid: stakeholders weten wanneer ze het resultaat ontvangen. Binnen de sprint beslist het team zelf hoe het werk wordt verdeeld. De Scrum Master beschermt het team tegen externe inmenging — nieuwe taken worden niet aan de huidige sprint toegevoegd. Volgens de Scrum Guide 2025 is dit de enige manier om een duurzaam ontwikkelingstempo (sustainable pace) te behouden.

Een sprint bestaat uit vier verplichte gebeurtenissen: Sprint Planning (planning), Daily Scrum (dagelijkse synchronisatie), Sprint Review (demonstratie van het resultaat), Sprint Retrospective (procesanalyse). Tussen deze gebeurtenissen door vindt het hoofdwerk plaats: taakuitvoering, testen, code review. De duur van elke gebeurtenis is evenredig aan de sprintsduur: voor een sprint van 2 weken duurt Planning 4 uur, Review 2 uur, Retro 1,5 uur en Daily 15 minuten. In totaal nemen de rituelen ongeveer 8 uur per sprint in beslag — 10% van de werktijd van het team.

Scrum-rituelen van de sprint

Scrum-rituelen (ceremonies/gebeurtenissen) — gestructureerde teamvergaderingen binnen de sprint. Sprint Planning aan het begin, Daily Scrum elke dag, Sprint Review en Retrospective aan het einde. Alle gebeurtenissen hebben een timebox (tijdslimiet). De Scrum Master ziet toe op naleving van de timebox en focus. Aan elk ritueel neemt het hele Scrum-team deel: Product Owner, Scrum Master, ontwikkelaars. Uitzondering — Daily Scrum (alleen ontwikkelaars nemen deel, PO en SM optioneel).

Verband tussen rituelen en sprintfasen: Planning geeft richting (wat en hoe we doen), Daily synchroniseert (wie wat doet, welke blokkades), Review toont het resultaat (wat is gedaan, wat niet), Retrospective verbetert het proces (hoe de volgende sprint beter te maken). Het overslaan van de retrospectieve — de meest voorkomende fout van teams: wanneer deadlines dreigen, wordt juist Retro opgeofferd. Dit leidt tot stagnatie van processen en herhaling van dezelfde fouten. Onderzoek van Scrum.org (2025) toont aan: teams die elke 2 weken een Retro houden, verbeteren hun velocity 35% sneller.

Sprint Planning: iteratieplanning

Sprint Planning — teamvergadering aan het begin van de sprint waarin wordt bepaald wat er wordt gedaan en hoe. De Product Owner presenteert de prioritaire taken uit de Product Backlog. Het team beoordeelt de capacity (beschikbare tijd rekening houdend met vakanties, vergaderingen, technische schuld) en selecteert taken die het in de sprint kan voltooien. Het resultaat van Planning is Sprint Goal (sprintdoel) en Sprint Backlog (takenlijst). Sprint Goal wordt geformuleerd als een korte zin: „Bestellingscherm en betalingsintegratie realiseren”.

Velocity — de snelheid van het team, gemeten in story points per sprint. Het gemiddelde van de laatste 3-5 sprints. Volgens Scrum.org (2025) heeft een team van 5 mobiele ontwikkelaars (3 Android + 2 iOS) een velocity van 25-40 SP voor een sprint van 2 weken. Planning gebruikt velocity als bovengrens — ze nemen 10-15% minder voor onvoorziene taken (code review, incidenten, hulp aan andere teams). Capacity vs Velocity: capacity is „menuren”, velocity is „story points”. Capacity houdt rekening met vakanties, ziekte, vergaderingen. Typische loss rate — 25-30% van de werktijd gaat naar niet-code gerelateerde activiteiten.

Planning bestaat uit twee delen: „wat” (PO vertelt over taken, team verduidelijkt) — 2 uur, en „hoe” (team deconstrueert en schat in) — 2 uur. Voor mobiele projecten wordt in het „hoe”-deel besproken: compatibiliteit met Android/iOS-versies, noodzaak van feature flags, impact op APK/IPA-grootte, nieuwe machtigingen. De Planning Poker-techniek wordt gebruikt voor schatting: elke ontwikkelaar geeft zijn schatting in story points (1, 2, 3, 5, 8, 13). Een verschil van > 2 eenheden — ze bespreken de redenen. Dit brengt verborgen risicoën in de planningsfase aan het licht, niet halverwege de sprint.

Uitvoering van de sprint: Daily Standup en tracking

Daily Scrum (Standup) — dagelijkse 15-minuten durende bijeenkomst voor teamsynchronisatie. Elke deelnemer beantwoordt drie vragen: „Wat heb ik gisteren gedaan?”, „Wat ben ik vandaag van plan?”, „Welke blokkades zijn er?”. Daily is geen statusrapport voor de manager, maar een instrument voor zelforganisatie van het team. Als tijdens Daily blijkt dat twee ontwikkelaars aan dezelfde taak werken, is dat een signaal voor reorganisatie. Belangrijk: Daily lost problemen niet op, maar identificeert ze — voor oplossing wordt na Daily een aparte bijeenkomst belegd.

Scrum Board (sprintbord) — visualisatie van de Sprint Backlog. Kolommen: To Do / In Progress / In Review / Done. Elke taak beweegt over het bord. Burndown Chart — grafiek van resterend werk per sprintdag. Ideale burndown — een rechte lijn van total SP naar 0. Werkelijke burndown — een getrapte grafiek rekening houdend met het afsluiten van taken. Dalende burndown (onder de ideale lijn) — we lopen achter. Probleemsignaal: als halverwege de sprint minder dan 30% van de taken is voltooid — is correctie nodig. Mogelijk zijn risico’s niet meegenomen of taken overschat.

Voor mobiele ontwikkeling wordt de sprinttracking beïnvloed door specifieke factoren: bouwtijd (het bouwen van een Android-project in CI kan 30+ minuten duren), wachten op moderatie van App Store / Google Play (als een build aan testers moet worden geleverd via TestFlight), compatibiliteit met verschillende apparaten (testen op 10+ modellen kost tijd). Advies: plan 1 dag buffer aan het einde van de sprint voor eindtesten en het bouwen van de releaseversie. Dit vermindert het risico op een onvoltooide sprint met 40% volgens Mind the Product (2025).

Sprint Review en Retrospective

Sprint Review — demonstratie van het increment aan stakeholders. Het team toont een werkende app-build, geen dia’s. Duur — 2 uur voor een sprint van 2 weken. De Product Owner controleert de naleving van de Acceptance Criteria. Stakeholders geven feedback die de Product Backlog kan beïnvloeden. Review is geen rapport, maar een dialoog: stakeholders kunnen vragen stellen en wijzigingen voorstellen. Belangrijkste regel: Sprint Review gaat over het product, niet over het proces. We laten zien wat er is bereikt, niet hoe we het hebben gedaan.

Sprint Retrospective — interne teamvergadering voor analyse van de afgelopen sprint. Formaat: Start Doing (wat te beginnen), Stop Doing (wat te stoppen), Continue Doing (wat te continueren). Duur — 1,5 uur voor een sprint van 2 weken. Retrospective is een veilige ruimte voor het bespreken van problemen. Regel: in Retro worden geen technische details besproken (daarvoor zijn er technische bijeenkomsten). Alleen proces, communicatie, tools, cultuur. De Scrum Master faciliteert de bijeenkomst en zorgt dat elke deelnemer aan het woord komt.

Het resultaat van Retrospective — 1-3 verbeteringen voor de volgende sprint. Als het team het probleem „Code review duurt te lang” heeft geïdentificeerd — action item: „Stel SLA voor review in — 4 uur. Als review niet op tijd is gedaan, herinnert de ontwikkelaar via Slack”. Action Items moeten concreet, meetbaar en aan een specifiek persoon toegewezen zijn. Volgens Atlassian (2025) verbeteren teams die hun Retro-action items uitvoeren hun velocity met 15-25% binnen 3-4 sprints. Teams die dat niet doen, blijven ter plaatse trappelen.

Hoe de sprintsduur te kiezen

2 weken — standaard voor mobiele ontwikkeling. Optimale balans tussen voorspelbaarheid en flexibiliteit. Voldoende om te plannen, 3-5 middelgrote features te implementeren, te testen en resultaat te tonen. 1 week — voor teams met een hoge procesvolwassenheid en CI/CD. Vereist snelle beslissingen, minimale bureaucratie. Geschikt voor startups in een vroeg stadium die snel moeten experimenteren. Nadeel: hoge overhead voor rituelen (elke week Planning + Review + Retro = 7,5 uur).

3-4 weken — voor complexe projecten met hardware-integratie (wearables, IoT, BLE-apparaten), lange winkelmoderatie of grote migraties (bijv. overstap van RxJava naar Coroutines). Lange sprints geven meer tijd voor testen, maar verhogen het risico op het „watervaleffect” — het team verliest Agile-flexibiliteit. Aanbeveling Scrum Guide: overschrijd 1 maand niet. Als de sprint langer is, zal er tijdens Review te veel context zijn en kunnen stakeholders geen kwalitatieve feedback geven.

Typische sprintproblemen

Probleem 1: Scope Creep. Halverwege de sprint voegt de Product Owner een nieuwe „spoedeisende en belangrijke” taak toe. Het team gaat akkoord — en de sprint mislukt. Oplossing: Sprint Goal is een contract. Elke wijziging vereist herziening van het Sprint Goal, en dit is alleen in noodgevallen mogelijk. De nieuwe taak gaat naar de Product Backlog en de volgende sprint. Als de taak echt kritiek is — wordt het oude Sprint Goal geannuleerd, de sprint opnieuw gepland, maar dit is een uitzondering, geen praktijk. Frequentie van scope creep vaker dan 1 keer per 3 sprints — teken van een zwakke Product Owner.

Probleem 2: Onvoltooide taken. Aan het einde van de sprint is 50% van de taken In Progress, 20% In Review, slechts 30% Done. Oorzaken: overschatting van capacity, onderschatting van complexiteit, ongeplande bugs. Oplossing: analyseer de oorzaak tijdens Retro. Als u systematisch niet op tijd bent — verhoog dan niet het aantal taken in Planning, maar verlaag het. Teams die 20% minder taken nemen, laten een hoger voltooiingspercentage zien (80%+ versus 50-60%). Checklist voor Planning: controleer voor elke taak de Acceptance Criteria, Definition of Ready en afhankelijkheden van andere taken.

Probleem 3: Formele Retro. Het team houdt Retro voor de vorm — 15 minuten, algemene zinnen, geen action items. Oplossing: verander het formaat van elke Retro. Methoden: Sailboat (wat vertraagt, wat versnelt), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Wijs action items toe met deadline en verantwoordelijke. Controleer aan het begin van de volgende Retro de uitvoering van eerdere action items. Volgens Atlassian (2025) genereren teams die verschillende Retro-formaten gebruiken 50% meer bruikbare inzichten.