Sprint i mobilutveckling: vad det är, längd och planering

Vad är en sprint i utveckling?

Sprint — ett tidsintervall (timebox) med fast längd, i slutet av vilket teamet levererar en färdig produktinkrement redo att användas. Sprintkonceptet är grunden i Scrum, men används även i andra Agile-ramverk. Inom mobilutveckling är en inkrement en appbuild som kan installeras på en enhet, testas och visas för intressenter. En sprint kan inte förlängas — om uppgifterna inte är klara flyttas de till nästa sprint.

Den viktigaste egenskapen hos en sprint är fast längd. Teamet ändrar inte sprintens mål efter att det godkänts. Det ger förutsägbarhet: intressenterna vet när de får resultatet. Inom sprinten bestämmer teamet själv hur arbetet fördelas. Scrum Master skyddar teamet från yttre påverkan — nya uppgifter läggs inte till i den aktuella sprinten. Enligt Scrum Guide 2025 är detta det enda sättet att hålla en hållbar utvecklingstakt (sustainable pace).

En sprint består av fyra obligatoriska evenemang: Sprint Planning (planering), Daily Scrum (daglig synkronisering), Sprint Review (demonstration av resultatet), Sprint Retrospective (analys av processen). Däremellan ligger huvudarbetet: genomförande av uppgifter, testning, kodgranskning. Varaktigheten för varje evenemang är direkt proportionell mot sprintens längd: för en tvåveckorssprint — Planning 4 timmar, Review 2 timmar, Retro 1.5 timmar, Daily 15 minuter. Totalt upptar ritualerna cirka 8 timmar per sprint — 10% av teamets arbetstid.

Scrums sprintritualer

Scrum-ritualer (ceremonier/evenemang) — strukturerade teammöten inom sprinten. Sprint Planning — i början, Daily Scrum — varje dag, Sprint Review och Retrospective — i slutet. Alla evenemang har en timebox (tidsbegränsning). Scrum Master ser till att timebox och fokus upprätthålls. Vid varje ritual deltar hela Scrum-teamet: Product Owner, Scrum Master, utvecklare. Undantag — Daily Scrum (endast utvecklare deltar, PO och SM — valfritt).

Kopplingen mellan ritualer och sprintens faser: Planning anger riktningen (vad och hur vi gör), Daily synkroniserar (vem gör vad, vilka blockeringar finns), Review visar resultatet (vad som gjordes, vad som inte gjordes), Retrospective förbättrar processen (hur nästa sprint kan bli bättre). Att hoppa över retrospektiven — det vanligaste teamfelet: när tidsfristerna brinner offras just Retro. Det leder till stagnerade processer och upprepning av samma misstag. En undersökning från Scrum.org (2025) visar: team som håller Retro varannan vecka förbättrar velocity 35% snabbare.

Sprint Planning: planering av iterationen

Sprint Planning — ett teammöte i början av sprinten där man bestämmer vad som ska göras och hur. Product Owner presenterar prioriterade uppgifter från Product Backlog. Teamet uppskattar capacity (tillgänglig tid med hänsyn till semester, möten, teknisk skuld) och väljer uppgifter som det kan klara under sprinten. Resultatet av Planning — Sprint Goal (sprintens mål) och Sprint Backlog (lista över uppgifter). Sprint Goal formuleras som en kort mening: “Implementera beställningsskärmen och betalningsintegration via SBP”.

Velocity — teamets hastighet, mätt i story points per sprint. Genomsnittet över de senaste 3-5 sprintarna. Enligt Scrum.org (2025) har ett team med 5 mobilutvecklare (3 Android + 2 iOS) en velocity på 25-40 SP per tvåveckorssprint. Planning använder velocity som övre gräns — man tar 10-15% mindre för oförutsedda uppgifter (code review, incidenter, hjälp till andra team). Capacity vs Velocity: capacity är “mantimmar”, velocity är “story points”. Capacity tar hänsyn till semester, sjukdom, möten. Typisk förlustfrekvens — 25-30% av arbetstiden går åt till icke-kodrelaterad aktivitet.

Planeringen delas i två delar: “vad” (PO berättar om uppgifterna, teamet förtydligar) — 2 timmar, och “hur” (teamet dekomponerar och uppskattar) — 2 timmar. För mobilprojekt diskuteras vid “hur”: kompatibilitet med Android/iOS-versioner, behov av feature flag, påverkan på APK/IPA-storlek, nya behörigheter. Tekniken Planning Poker används för uppskattning: varje utvecklare ger sin uppskattning i story points (1, 2, 3, 5, 8, 13). Avvikelser > 2 enheter — orsakerna diskuteras. Det avslöjar dolda risker i planeringsfasen, inte mitt i sprinten.

Genomförande av sprinten: Daily Standup och uppföljning

Daily Scrum (Standup) — ett dagligt 15-minutersmöte för teamsynkronisering. Varje deltagare svarar på tre frågor: “Vad gjordes igår?”, “Vad planerar jag idag?”, “Vilka blockeringar finns?”. Daily är inte en statusrapport till chefen utan ett verktyg för teamets självorganisering. Om det visar sig på Daily att två utvecklare arbetar på samma uppgift — är det en signal för omorganisering. Viktigt: Daily löser inte problem, utan identifierar dem — för lösning kallas ett separat möte efter Daily.

Scrum Board (sprinttavlan) — en visualisering av Sprint Backlog. Kolumner: To Do / In Progress / In Review / Done. Varje uppgift flyttas runt på tavlan. Burndown Chart — en graf över återstående arbete per sprintdag. En ideal burndown är en rak linje från total SP till 0. En verklig burndown — en trappstegsgraf som tar hänsyn till avslutade uppgifter. En sjunkande burndown (under den ideala linjen) — vi ligger efter. Problemsignal: om mindre än 30% av uppgifterna är klara vid mitten av sprinten — krävs en justering. Kanske har risker inte beaktats eller uppgifterna är överskattade.

För mobilutveckling påverkas sprintuppföljningen av specifika faktorer: byggtid (en Android-byggnad i CI kan ta 30+ minuter), väntan på moderering i App Store / Google Play (om en build måste släppas till testare via TestFlight), kompatibilitet med olika enheter (testning på 10+ modeller tar tid). Råd: planera in 1 buffertdag i slutet av sprinten för sluttestning och byggande av release-builden. Det minskar risken för en oavslutad sprint med 40% enligt Mind the Product (2025).

Sprint Review och Retrospective

Sprint Review — demonstration av inkrementet för intressenterna. Teamet visar en fungerande appbuild, inte bildspel. Varaktighet — 2 timmar för en tvåveckorssprint. Product Owner kontrollerar att Acceptance Criteria uppfylls. Intressenterna ger feedback som kan påverka Product Backlog. Review är inte en rapport, utan en dialog: intressenterna kan ställa frågor och föreslå ändringar. Nyckelregel: Sprint Review handlar om produkten, inte om processen. Vi visar vad som blev gjort, inte hur vi arbetade.

Sprint Retrospective — ett internt teammöte för att analysera den avslutade sprinten. Format: Start Doing (vad som ska börja göras), Stop Doing (vad som ska sluta), Continue Doing (vad som ska fortsätta). Varaktighet — 1.5 timmar för en tvåveckorssprint. Retrospective är ett tryggt utrymme för att diskutera problem. Regel: på Retro diskuteras inte tekniska detaljer (för det finns tekniska möten). Bara process, kommunikation, verktyg, kultur. Scrum Master faciliterar mötet och ser till att varje deltagare får komma till tals.

Resultatet av Retrospective är 1-3 förbättringar till nästa sprint. Om teamet identifierat problemet “För långsam code review” — blir action item: “Sätt SLA på granskningen — 4 timmar. Om granskningen inte gjorts i tid — påminner utvecklaren i Slack”. Action Items måste vara konkreta, mätbara och tilldelade en specifik person. Enligt Atlassian (2025) förbättrar team som genomför sina Retro action items velocity med 15-25% under 3-4 sprintar. De som inte gör det — står stilla.

Hur man väljer sprintlängd

2 veckor — standard inom mobilutveckling. Optimal balans mellan förutsägbarhet och flexibilitet. Man hinner: planera, genomföra 3-5 medelstora funktioner, testa, visa resultatet. 1 vecka — för team med mogen process och CI/CD. Kräver snabba beslut och minimal byråkrati. Passar för tidiga startups när man snabbt behöver experimentera. Nackdel: hög overhead för ritualer (varje vecka Planning + Review + Retro = 7.5 timmar).

3-4 veckor — för komplexa projekt där integration med hårdvara (wearables, IoT, BLE-enheter), lång butiksmoderering eller stora migreringar (till exempel övergång från RxJava till Coroutines). Långa sprintar ger mer tid för testning, men ökar risken för “vattenfallseffekten” — teamet tappar agile-flexibilitet. Rekommendation från Scrum Guide: överstig inte 1 månad. Om sprinten är längre — blir det för mycket kontext på Review och intressenterna kan inte ge kvalitativ feedback.

Vanliga problem med sprintar

Problem 1: Scope Creep. Mitt i sprinten lägger Product Owner till en ny “brådskande och viktig” uppgift. Teamet går med på det — och sprinten misslyckas. Lösning: Sprint Goal är ett kontrakt. Varje ändring kräver att Sprint Goal omprövas, och det är bara möjligt i nödfall. Den nya uppgiften går till Product Backlog och till nästa sprint. Om uppgiften verkligen är kritisk — annulleras det gamla Sprint Goal, sprinten planeras om, men det är ett undantag, inte en praxis. Frekvens av scope creep oftare än en gång per 3 sprintar — ett tecken på en svag Product Owner.

Problem 2: Oavslutade uppgifter. I slutet av sprinten är 50% av uppgifterna i In Progress, 20% i Review, bara 30% Done. Orsaker: överskattad capacity, underskattad komplexitet, oplanerade buggar. Lösning: analysera orsaken på Retro. Om ni systematiskt inte hinner — öka inte antalet uppgifter vid Planning, utan minska det. Team som tar 20% färre uppgifter visar en högre slutförandeprocent (80%+ jämfört med 50-60%). Checklista för Planning: för varje uppgift kontrollera Acceptance Criteria, Definition of Ready och beroenden till andra uppgifter.

Problem 3: Formella Retro. Teamet håller Retro för syns skull — 15 minuter, allmänna fraser, utan action items. Lösning: ändra format för varje Retro. Metoder: Sailboat (vad som bromsar, vad som påskyndar), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Tilldela action items med deadline och ansvarig. I början av nästa Retro kontrollera att tidigare action items genomförts. Enligt Atlassian (2025) genererar team som använder olika Retro-format 50% fler användbara insikter.