Daily och stand-up — vad det är, regler för dagligt möte och nytta

Vad är daily och stand-up?

Daily Standup (daglig stand-up, daily) — kort möte för Scrum-teamet, som hålls på samma tid och plats varje arbetsdag. Timebox — 15 minuter. Förekommer under olika namn: Daily Scrum (i Scrum Guide), morgonsynkronisering, morning circle, daily. Syftet är att synkronisera teamet, identifiera blockeringar och justera dagens planer. Daily är inte en rapport till chefen, utan ett verktyg för teamets självorganisering. Teamet bestämmer hur mötet ska struktureras, inte chefen.

Ursprunget till termen “stand-up” — från praxis att bokstavligen stå under mötet: deltagarna samlas vid tavlan och sätter sig inte. Detta skapar en känsla av tillfällighet — ingen vill stå längre än 15 minuter. Fysisk stand-up används fortfarande i 60% av teamen (enligt Scrum.org 2025), resten har övergått till distansformat via Zoom, Slack Huddle eller Teams. I distansformat är disciplin viktigt: påslagna kameror, ingen multitasking, beredskap att tänka igenom svar i förväg.

Scrum Guide 2025 definierar Daily Scrum som en händelse för Developers (utvecklare). Product Owner och Scrum Master kan närvara, men är inte skyldiga. Om PO eller SM närvarar — leder de inte mötet. Teamet väljer själv struktur: klassiska tre frågor eller board walk. Nyckeln: daily handlar om att inspektera framsteg mot Sprint Goal, inte om status för varje task. Om mötet förvandlas till en uppräkning av tasks på tavlan — har teamet förlorat fokus på Sprint Goal.

De tre frågorna i Daily Standup

Fråga 1: “Vad gjorde jag igår för att nå Sprint Goal?” — kort lista över slutförda uppgifter. Inte “jag arbetade på APP-123”, utan “slutförde inloggningsskärmen, PR skickad för granskning”. Formuleringen “för att nå Sprint Goal” är inte slumpmässig — den kopplar det dagliga arbetet till sprintens övergripande mål. Om utvecklaren inte ser kopplingen mellan sin uppgift och Sprint Goal — är det en signal att uppgiften inte behövs i den aktuella sprinten. Inom mobilutveckling är gårdagens resultat inte bara kod, utan även tester, dokumentation, CI/CD-konfiguration.

Fråga 2: “Vad planerar jag att göra idag för att nå Sprint Goal?” — plan för dagen. Högst 2-3 punkter. Utvecklaren kan säga: “Idag slutför jag ViewModel för profilsidan, skriver enhetstester, kör bygget på en riktig enhet”. Om planen sammanfaller med “igår” — är det en signal att uppgiften är för stor och måste delas upp. Tvådagarsregeln: om en uppgift inte slutförs inom 2 arbetsdagar — måste den delas upp i deluppgifter, annars fastnar den i In Progress i veckor.

Fråga 3: “Vilka blockeringar hindrar mina framsteg?” — den viktigaste frågan. En blockering är något utvecklaren inte kan lösa själv: väntar på granskning (om SLA för granskning har löpt ut), emulatorn fungerar inte, API är inte klart, behöver åtkomst till repository. Viktigt: blockeringen ska nämnas men inte lösas på daily. Efter mötet kommer utvecklaren och Scrum Master / chef överens om lösningen. Enligt Scrum.org (2025) är 70% av blockeringarna i mobila team relaterade till: väntan på granskning (30%), otillgänglighet av testenheter (20%), beroenden av backend (20%).

Hur man genomför stand-up korrekt

Tid och plats. Daily hålls på samma tid varje dag — vanligtvis i början av arbetsdagen (9:00-10:00). För distribuerade team väljs en tid som är bekväm för alla tidszoner. Längd — strikt 15 minuter. Timer — obligatorisk. Om teamet inte hinner — ligger problemet inte i daily, utan i processen: antingen är det för många deltagare, eller så diskuteras uppgifterna istället för att bara nämnas. Ping-pong-regeln: varje deltagare talar högst 60 sekunder. Efter svaret överlämnas ordet till nästa.

Formatet “tavla runt” (Board Walk). Alternativ till de tre frågorna: teamet flyttar i tur och ordning uppgifter på Scrum-tavlan och kommenterar ändringar. Utvecklaren tar sin task från To Do, flyttar till In Progress och säger: “Jag tar APP-123 — beställningsskärm, lägger till fält för kampanjkod”. Board Walk ger visuell förståelse för framsteg och avslöjar “glömda” tasks — de som står stilla i 3+ dagar. Board Walk är att föredra för distribuerade team med Jira/Linear — alla ser tavlan, inte lyssnar på en monolog.

För distansteam: obligatoriska påslagna kameror — enligt Microsoft Research (2025) ökar påslagen kamera engagemanget med 40%. Använd delad skärm med uppgiftstavla (Jira, Linear, Miro). Skriv blockeringar i chatten — det skapar en skriftlig registrering. Uppmuntra reaktions-emoji (förutom användarens kommando — emoji används inte) — tumme upp på en kollegas meddelande. Efter daily — 2-3 minuter för “parkering” (parking lot): ämnen som kräver separat diskussion antecknas i listan över follow-up-möten. Scrum Masters nyckelfärdighet: stoppa diskussionen på daily och flytta den till parking lot.

Typiska misstag vid genomförande

Misstag 1: statusrapport till chefen. Utvecklare läser i tur och ordning vad som står i Jira, chefen ställer förtydligande frågor, mötet varar i 45 minuter. Lösning: påminn om att daily är för teamet, inte för chefen. Chefen kan ta reda på status från tavlan. Om chefen ställer frågor — flytta dem till 1:1. Teamet som förvandlat daily till en rapport förlorar 2-3 timmar per vecka på alla deltagare. Med 8 utvecklare är det 16-24 arbetstimmar per månad — förlust av en hel sprint per år.

Misstag 2: lösa problem på plats. Utvecklaren säger “Jag har en bugg med GRPC — projektet bygger inte” och hela teamet diskuterar lösningar i 20 minuter. Lösning: anteckna blockeringen i parking lot, fortsätt daily. Efter mötet — samla intresserade (utvecklaren + någon som kan hjälpa) för en 10-minuters diskussion. Enligt Basecamp (Shape Up) kräver endast 20% av problemen som upptäcks på daily diskussion av hela teamet. Resten löses av ett par utvecklare på 10 minuter.

Misstag 3: förseningar och frånvaro. Någon kommer 5 minuter efter start — måste upprepas. Lösning: fastställ regeln “daily börjar i tid, sena kommer inte in” eller ”en sen betalar böter” (kaffe till teamet). Ännu strängare: daily hålls på samma tid, om någon systematiskt kommer sent — är det en fråga om disciplin, löses i 1:1. Daily är dagens synkronisering. Om utvecklaren missade — är han inte synkroniserad och riskerar att göra arbete som teamet inte behöver.

Misstag 4: för många deltagare. Team på 15+ personer, var och en talar en minut — totalt 20+ minuter. Lösning: dela teamet i undergrupper efter funktion/modul. Varje undergrupp håller sin egen daily (5-7 personer). En representant från undergruppen kan komma till det gemensamma cross-team stand-up (om synkronisering mellan team behövs). Alternativ: asynkron stand-up via Slack/GeekBot, där var och en skriver vad de gjort/planerar/blockeringar.

Asynkron stand-up: alternativ

Asynkron stand-up — ett format där deltagarna skriver sina svar i chatten (Slack, Telegram, Teams) eller via en specialiserad bot (GeekBot, Standuply, Status Hero) istället för ett muntligt möte. Lämplig för distribuerade team med tidsskillnad på 3+ timmar. Varje deltagare svarar på samma tre frågor före en viss tid (t.ex. före 11:00). Boten samlar in svaren och publicerar en sammanfattning på den gemensamma kanalen. Fördelar: flexibilitet, skriftlig registrering, inget problem med förseningar.

Nackdelar med asynkront format: ingen levande kommunikation — icke-verbala signaler går förlorade, svårare att identifiera blockeringar (utvecklaren kanske inte skriver om problemet). En blockering skriven i chatten kan förbli obemärkt till slutet av dagen. Enligt GitLab (2025) återvände 40% av teamen som gick över till async stand-up till muntligt inom 3 månader. Rekommendation: använd hybrid — 3 dagar muntlig stand-up (mån, ons, fre), 2 dagar asynkron (tis, tors). Eller: muntlig stand-up 1-2 gånger i veckan, övriga dagar — asynkron.

Verktyg för asynkron stand-up: GeekBot (Slack) — ställer tre frågor, publicerar sammanfattning; Standuply — med Jira-integration, automatisk spårning; Status Hero — samlar in statusar och skapar veckorapport för ledningen. Valet av verktyg beror på teamkulturen: i startups räcker en bot i Slack, i enterprise kan Standuply med integration i företagsprocesser behövas. Viktig regel: oavsett format ska svaren vara synliga för hela teamet, inte bara för chefen. Transparens är ett kärnvärde i Agile.

Särdrag för daily i mobila team

Mobila teamet stöter på specifika blockeringar på daily. Huvudsakliga: bygga projektet i CI (Gradle build kan ta 20+ minuter — om det går sönder förlorar utvecklaren en timme på diagnos), väntan på TestFlight / Firebase App Distribution (publicering av build för testare tar 30-60 minuter), problem med emulatorer och simulatorer (Android Emulator kräver KVM/HAXM, iOS Simulator endast på Mac). Mobila teamets daily bör inkludera en snabb kontroll av buildstatus: “Bygger det? Alla tester är gröna?”

För cross-platform-projekt (Flutter, React Native) kan daily inkludera en fråga om status för delad kod. Om två utvecklare samtidigt redigerar samma Dart-fil och en av dem slår samman ändringar — kommer den andra att få konflikter. Råd: använd Board Walk på en tavla med indelning efter plattform (Android / iOS / Shared). Detta hjälper att se vem som arbetar var och om ändringar överlappar. För Flutter-projekt — en tavla med kolumner Platform Channel, BLoC/Cubit, UI, Tests.

Release-beredskap — ytterligare en specifik punkt för mobil utveckling i daily. 3-5 dagar före release lägg till frågan: “Är bygget redo för release? All metadata (ikoner, skärmdumpar, beskrivning) uppdaterad?” Detta förhindrar situationen där utvecklare slutför koden på releasedagen och byggande och publicering tar ytterligare 3-4 timmar. Release tracker — separat tavla med checklista: uppdatering versionCode/versionName, ProGuard-kontroll, AAB-signering, uppladdning till utvecklarkonsolen, release notes.