Daily en stand-up — wat is het, regels van de dagelijkse bijeenkomst en voordelen

Wat is daily en stand-up?

Daily Standup (dagelijkse stand-up, daily) — korte bijeenkomst van het Scrum-team, elke werkdag op dezelfde tijd en plaats. Timebox — 15 minuten. Komt onder verschillende namen voor: Daily Scrum (in Scrum Guide), ochtendsynchronisatie, morning circle, daily. Doel — het team synchroniseren, blokkades identificeren en de dagelijkse plannen bijstellen. Daily is geen rapport voor de manager, maar een hulpmiddel voor zelforganisatie van het team. Het team beslist hoe de bijeenkomst gestructureerd wordt, niet de manager.

De oorsprong van de term “stand-up” — van de praktijk om tijdens de bijeenkomst letterlijk te staan: deelnemers komen bij het bord samen en gaan niet zitten. Dit creëert een gevoel van tijdelijkheid — niemand wil langer dan 15 minuten staan. Fysieke stand-up wordt nog steeds in 60% van de teams gebruikt (volgens Scrum.org 2025), de rest is overgestapt op remote-formaat via Zoom, Slack Huddle of Teams. In remote-formaat is discipline belangrijk: camera's aan, geen multitasking, voorbereide antwoorden.

Scrum Guide 2025 definieert Daily Scrum als een evenement voor Developers (ontwikkelaars). Product Owner en Scrum Master kunnen aanwezig zijn, maar zijn niet verplicht. Als PO of SM aanwezig zijn — leiden zij de bijeenkomst niet. Het team kiest zelf de structuur: klassieke drie vragen of board walk. Sleutelpunt: daily gaat over het inspecteren van de voortgang naar het Sprint Goal, niet over de status van elke taak. Als de bijeenkomst verandert in het opsommen van taken op het bord — heeft het team de focus op Sprint Goal verloren.

Drie vragen van Daily Standup

Vraag 1: “Wat heb ik gisteren gedaan om het Sprint Goal te bereiken?” — korte lijst van voltooide taken. Niet “ik werkte aan APP-123”, maar “het inlogscherm afgerond, PR naar review gestuurd”. De formulering “om het Sprint Goal te bereiken” is niet toevallig — het verbindt dagelijks werk met het algemene sprintdoel. Als een ontwikkelaar geen verband ziet tussen zijn taak en het Sprint Goal — is dat een signaal dat de taak niet nodig is in de huidige sprint. In mobiele ontwikkeling is het resultaat van gisteren niet alleen code, maar ook tests, documentatie, CI/CD-configuratie.

Vraag 2: “Wat ben ik van plan vandaag te doen om het Sprint Goal te bereiken?” — plan voor de huidige dag. Niet meer dan 2-3 punten. Een ontwikkelaar kan zeggen: “Vandaag maak ik de ViewModel voor het profielscherm af, schrijf ik unittesten, draai ik de build op een echt apparaat”. Als het plan overeenkomt met wat “gisteren” was — is dat een signaal dat de taak te groot is en opgesplitst moet worden. Tweedaagse regel: als een taak niet binnen 2 werkdagen is voltooid — moet deze worden opgedeeld in subtaken, anders blijft hij wekenlang in In Progress hangen.

Vraag 3: “Welke blokkades belemmeren mijn voortgang?” — de belangrijkste vraag. Een blokkade is iets wat de ontwikkelaar niet zelf kan oplossen: wacht op review (als de SLA voor review is verstreken), emulator werkt niet, API is niet klaar, toegang tot repository nodig. Belangrijk: de blokkade moet worden genoemd, maar niet opgelost tijdens de daily. Na de bijeenkomst komen de ontwikkelaar en Scrum Master / manager overeen over de oplossing. Volgens Scrum.org (2025) is 70% van de blokkades van een mobiel team gerelateerd aan: wachten op review (30%), niet-beschikbaarheid van testapparaten (20%), afhankelijkheden van backend (20%).

Hoe voer je een stand-up correct uit

Tijd en plaats. Daily vindt elke dag op hetzelfde tijdstip plaats — meestal aan het begin van de werkdag (9:00-10:00). Voor gedistribueerde teams wordt een tijd gekozen die comfortabel is voor alle tijdzones. Duur — strikt 15 minuten. Timer — verplicht. Als het team niet binnen de tijd blijft — ligt het probleem niet aan de daily, maar aan het proces: ofwel zijn er te veel deelnemers, ofwel worden taken besproken in plaats van alleen genoemd. Pingpongregel: elke deelnemer spreekt maximaal 60 seconden. Na het antwoord geeft hij het woord door aan de volgende.

Format “bord rondgang” (Board Walk). Alternatief voor de drie vragen: het team verplaatst om de beurt taken op het Scrum-bord en licht wijzigingen toe. De ontwikkelaar pakt zijn taak uit To Do, verplaatst naar In Progress en zegt: “Ik neem APP-123 — bestelscherm, voeg promotiecodeveld toe”. Board Walk geeft visueel inzicht in de voortgang en onthult “vergeten” taken — die welke 3+ dagen onbeweeglijk blijven. Board Walk heeft de voorkeur voor gedistribueerde teams met Jira/Linear — iedereen ziet het bord, luistert niet naar een monoloog.

Voor remote teams: camera's verplicht aan — volgens Microsoft Research (2025) verhoogt een ingeschakelde camera de betrokkenheid met 40%. Gebruik een gedeeld scherm met het takenbord (Jira, Linear, Miro). Schrijf blokkades in de chat — dit creëert een schriftelijke registratie. Moedig reactie-emoji's aan (behalve gebruikersopdracht — emoji's worden niet gebruikt) — duim omhoog op een bericht van een collega. Na de daily — 2-3 minuten voor “parking lot”: onderwerpen die aparte discussie vereisen, worden genoteerd in de follow-up vergaderlijst. Belangrijke vaardigheid van de Scrum Master: stop de discussie tijdens de daily en verplaats deze naar de parking lot.

Typische fouten bij het houden

Fout 1: statusrapport voor de manager. Ontwikkelaars lezen om de beurt voor wat er in Jira staat, de manager stelt verduidelijkende vragen, de bijeenkomst duurt 45 minuten. Oplossing: herinner eraan dat de daily voor het team is, niet voor de manager. De manager kan de status van het bord aflezen. Als de manager vragen stelt — verplaats ze naar 1:1. Een team dat de daily in een rapport heeft veranderd, verliest 2-3 uur per week aan alle deelnemers. Bij 8 ontwikkelaars is dat 16-24 mensuren per maand — verlies van een hele sprint per jaar.

Fout 2: problemen ter plekke oplossen. Een ontwikkelaar zegt “Ik heb een bug met GRPC — het project compileert niet” en het hele team discussieert 20 minuten over oplossingen. Oplossing: noteer de blokkade in parking lot, ga door met de daily. Na de bijeenkomst — verzamel de belanghebbenden (ontwikkelaar + iemand die kan helpen) voor een 10-minuten durende discussie. Volgens Basecamp (Shape Up) vereist slechts 20% van de problemen die tijdens de daily worden ontdekt, discussie door het hele team. De rest wordt door een paar ontwikkelaars in 10 minuten opgelost.

Fout 3: te laat komen en afwezigheid. Iemand komt 5 minuten na aanvang — er moet worden herhaald. Oplossing: stel de regel in “daily begint op tijd, laatkomers gaan niet naar binnen” of “laaitje betaalt een boete” (koffie voor het team). Nog strenger: de daily vindt op hetzelfde tijdstip plaats, als iemand systematisch te laat komt — is dat een kwestie van discipline, op te lossen in 1:1. Daily is de synchronisatie van de dag. Als een ontwikkelaar heeft gemist — is hij niet gesynchroniseerd en loopt hij het risico werk te doen dat het team niet nodig heeft.

Fout 4: te veel deelnemers. Team van 15+ personen, iedereen spreekt een minuut — totaal 20+ minuten. Oplossing: verdeel het team in subgroepen per feature/module. Elke subgroep houdt zijn eigen daily (5-7 personen). Eén vertegenwoordiger van de subgroep kan naar de gemeenschappelijke cross-team stand-up komen (als synchronisatie tussen teams nodig is). Alternatief: asynchrone stand-up via Slack/GeekBot, waar iedereen schrijft wat hij heeft gedaan/plant/blokkades.

Asynchrone stand-up: alternatieven

Asynchrone stand-up — een format waarbij deelnemers hun antwoorden in de chat (Slack, Telegram, Teams) of via een gespecialiseerde bot (GeekBot, Standuply, Status Hero) schrijven in plaats van een mondelinge bijeenkomst. Geschikt voor gedistribueerde teams met een tijdsverschil van 3+ uur. Elke deelnemer beantwoordt dezelfde drie vragen vóór een bepaalde tijd (bijv. vóór 11:00). De bot verzamelt de antwoorden en publiceert een samenvatting op het algemene kanaal. Voordelen: flexibiliteit, schriftelijke registratie, geen probleem met te laat komen.

Nadelen van het asynchrone format: geen live communicatie — non-verbale signalen gaan verloren, het is moeilijker om blokkades te identificeren (een ontwikkelaar schrijft mogelijk niet over een probleem). Een in de chat geschreven blokkade kan tot het einde van de dag onopgemerkt blijven. Volgens GitLab (2025) is 40% van de teams die naar async standup zijn overgestapt, binnen 3 maanden teruggekeerd naar mondeling. Aanbeveling: gebruik een hybride — 3 dagen mondelinge stand-up (ma, wo, vr), 2 dagen asynchroon (di, do). Of: mondelinge stand-up 1-2 keer per week, op de overige dagen — asynchroon.

Hulpmiddelen voor asynchrone stand-up: GeekBot (Slack) — stelt drie vragen, publiceert samenvatting; Standuply — met Jira-integratie, automatische tracking; Status Hero — verzamelt statussen en genereert wekelijks rapport voor het management. De keuze van het hulpmiddel hangt af van de teamcultuur: in startups is een bot in Slack voldoende, in enterprise kan Standuply met integratie in bedrijfsprocessen nodig zijn. Belangrijke regel: ongeacht het format moeten antwoorden zichtbaar zijn voor het hele team, niet alleen voor de manager. Transparantie — de kernwaarde van Agile.

Specifieke kenmerken van daily voor het mobiele team

Het mobiele team wordt tijdens de daily geconfronteerd met specifieke blokkades. Belangrijkste: het bouwen van het project in CI (Gradle build kan 20+ minuten duren — als het kapot is, verliest de ontwikkelaar een uur aan diagnose), wachten op TestFlight / Firebase App Distribution (publiceren van de build voor testers duurt 30-60 minuten), problemen met emulators en simulatoren (Android Emulator vereist KVM/HAXM, iOS Simulator alleen op Mac). Daily van het mobiele team moet een snelle check van de buildstatus bevatten: “Wordt de build gecompileerd? Zijn alle tests groen?”

Voor cross-platform projecten (Flutter, React Native) kan de daily een vraag over de status van gedeelde code bevatten. Als twee ontwikkelaars tegelijkertijd hetzelfde Dart-bestand bewerken en een van hen wijzigingen doorvoert — krijgt de tweede conflicten. Advies: gebruik Board Walk op een bord met indeling per platform (Android / iOS / Shared). Dit helpt te zien wie waar werkt en of wijzigingen overlappen. Voor Flutter-projecten — een bord met kolommen Platform Channel, BLoC/Cubit, UI, Tests.

Release-gereedheid — nog een specifiek punt voor mobiele ontwikkeling in de daily. Voeg 3-5 dagen voor de release de vraag toe: “Is de build klaar voor release? Zijn alle metadata (iconen, screenshots, beschrijving) bijgewerkt?” Dit voorkomt de situatie waarin ontwikkelaars de code op de releasedag afronden en het bouwen en publiceren nog 3-4 uur duurt. Release tracker — een apart bord met checklist: bijwerken van versionCode/versionName, ProGuard-controle, AAB-ondertekening, uploaden naar de ontwikkelaarsconsole, release notes.