Sprint a mobilfejlesztésben: lényeg, időtartam és tervezés

Mi az a sprint a fejlesztésben?

Sprint — egy fix időtartamú időintervallum (timebox), amelynek végén a csapat egy használatra kész terméknövekményt szállít le. A sprint koncepciója a Scrum alapja, de más Agile keretrendszerekben is használatos. A mobilfejlesztésben a növekmény egy app build, amely telepíthető egy eszközre, tesztelhető és megmutatható az érdekelt feleknek. A sprint nem hosszabbítható meg — ha a feladatok nem készülnek el, átkerülnek a következő sprintbe.

A sprint kulcsjellemzője a fix időtartam. A csapat nem változtatja meg a sprint célját a jóváhagyás után. Ez kiszámíthatóságot ad: az érdekelt felek tudják, mikor kapják meg az eredményt. A sprinten belül a csapat maga dönti el, hogyan osztja el a munkát. A Scrum Master védi a csapatot a külső beavatkozásoktól — új feladatok nem kerülnek a jelenlegi sprintbe. A Scrum Guide 2025 szerint ez az egyetlen mód a fenntartható fejlesztési tempó (sustainable pace) megtartására.

A sprint négy kötelező eseményből áll: Sprint Planning (tervezés), Daily Scrum (napi szinkronizálás), Sprint Review (eredmény bemutatása), Sprint Retrospective (folyamatelemzés). Közöttük — a fő munka: feladatok végrehajtása, tesztelés, kódáttekintés. Az egyes események időtartama arányos a sprint hosszával: egy 2 hetes sprintnél Planning — 4 óra, Review — 2 óra, Retro — 1,5 óra, Daily — 15 perc. Összesen a rituálék kb. 8 órát vesznek igénybe sprintenként — a csapat munkaidejének 10%-a.

A sprint Scrum-rituáléi

Scrum-rituálék (ceremóniák/események) — strukturált csapatmegbeszélések a sprint keretén belül. Sprint Planning — az elején, Daily Scrum — minden nap, Sprint Review és Retrospective — a végén. Minden esemény rendelkezik timebox-szal (időkorláttal). A Scrum Master felügyeli a timebox és a fókusz betartását. Minden rituálén részt vesz a teljes Scrum csapat: Product Owner, Scrum Master, fejlesztők. Kivétel — Daily Scrum (csak fejlesztők vesznek részt, PO és SM — opcionális).

A rituálék kapcsolata a sprint szakaszaival: Planning irányt ad (mit és hogyan csinálunk), Daily szinkronizál (ki mit csinál, milyen blokkolók vannak), Review megmutatja az eredményt (mi készült el, mi nem), Retrospective javítja a folyamatot (hogyan tehetjük jobbá a következő sprintet). A retrospektív kihagyása — a csapatok leggyakoribb hibája: amikor a határidők szorítanak, pont a Retro-t áldozzák fel. Ez a folyamatok stagnálásához és ugyanazon hibák ismétlődéséhez vezet. A Scrum.org (2025) kutatása azt mutatja: a kéthetente Retro-t tartó csapatok 35%-kal gyorsabban javítják a velocity-t.

Sprint Planning: az iteráció tervezése

Sprint Planning — csapatmegbeszélés a sprint elején, ahol meghatározzák, mi és hogyan készüljön el. A Product Owner bemutatja a prioritási sorrendben lévő feladatokat a Product Backlog-ból. A csapat felméri a kapacitást (capacity — rendelkezésre álló idő, figyelembe véve a szabadságokat, megbeszéléseket, technikai adósságot) és kiválasztja a sprintben elvégezhető feladatokat. A Planning eredménye — Sprint Goal (a sprint célja) és Sprint Backlog (feladatlista). A Sprint Goal egy rövid mondatként van megfogalmazva: „Rendelési képernyő és fizetési integráció megvalósítása”.

Velocity — a csapat sebessége, story pontokban mérve sprintenként. Az utolsó 3-5 sprint átlaga. A Scrum.org (2025) szerint egy 5 mobil fejlesztőből álló csapat (3 Android + 2 iOS) velocity-je 25-40 SP egy 2 hetes sprintben. A Planning a velocity-t használja felső határként — 10-15%-kal kevesebbet vállalnak a nem várt feladatokra (kódáttekintés, incidensek, más csapatok segítése). Capacity vs Velocity: capacity ”emberóra”, velocity ”story point”. A capacity figyelembe veszi a szabadságokat, betegséget, megbeszéléseket. Tipikus loss rate — a munkaidő 25-30%-a nem kódolással kapcsolatos tevékenységre megy el.

A tervezés két részre oszlik: „mit” (PO elmondja a feladatokat, a csapat tisztáz) — 2 óra, és „hogyan” (a csapat lebontja és becsli) — 2 óra. Mobil projektek esetén a „hogyan” részben megbeszélik: kompatibilitás az Android/iOS verziókkal, feature flag szükségessége, hatás az APK/IPA méretre, új engedélyek. A Planning Poker technikát használják a becsléshez: minden fejlesztő megadja a saját becslését story pontokban (1, 2, 3, 5, 8, 13). A 2 egységnél nagyobb eltérés esetén megbeszélik az okokat. Ez feltárja a rejtett kockázatokat a tervezési szakaszban, nem a sprint közepén.

A sprint végrehajtása: Daily Standup és nyomon követés

Daily Scrum (Standup) — napi 15 perces megbeszélés a csapat szinkronizálására. Minden résztvevő három kérdésre válaszol: „Mit csináltam tegnap?”, „Mit tervezek ma?”, „Milyen blokkolók vannak?”. A Daily nem status report a menedzsernek, hanem a csapat önszerveződésének eszköze. Ha a Daily során kiderül, hogy két fejlesztő ugyanazon a feladaton dolgozik — ez átszervezési jel. Fontos: a Daily nem oldja meg a problémákat, hanem azonosítja azokat — a megoldáshoz külön megbeszélést hívnak össze a Daily után.

Scrum Board (sprint tábla) — a Sprint Backlog vizualizációja. Oszlopok: To Do / In Progress / In Review / Done. Minden feladat mozog a táblán. Burndown Chart — a hátralevő munka grafikonja a sprint napjaira. Ideális burndown — egyenes vonal a total SP-től 0-ig. Valós burndown — lépcsős grafikon, figyelembe véve a feladatok lezárását. Csökkenő burndown (az ideális vonal alatt) — késünk. Probléma jelzés: ha a sprint felénél kevesebb mint 30% a feladatok kész — korrekció szükséges. Lehet, hogy nem vették figyelembe a kockázatokat, vagy túlbecsülték a feladatokat.

A mobilfejlesztésben a sprint nyomon követését specifikus tényezők befolyásolják: build idő (Android projekt CI-ban történő építése 30+ percet vehet igénybe), App Store / Google Play moderációjára várakozás (ha build-et kell szállítani a tesztelőknek TestFlight-on keresztül), kompatibilitás különböző eszközökkel (10+ modellen történő tesztelés időt vesz igénybe). Tanács: tervezzen 1 nap puffert a sprint végén a végleges tesztelésre és a release build elkészítésére. Ez a Mind the Product (2025) szerint 40%-kal csökkenti a befejezetlen sprint kockázatát.

Sprint Review és Retrospective

Sprint Review — a növekmény bemutatása az érdekelt feleknek. A csapat működő app build-et mutat, nem diákat. Időtartam — 2 óra egy 2 hetes sprint esetén. A Product Owner ellenőrzi az Acceptance Criteria-nak való megfelelést. Az érdekelt felek visszajelzést adnak, ami befolyásolhatja a Product Backlog-ot. A Review nem jelentés, hanem párbeszéd: az érdekelt felek kérdéseket tehetnek fel és változtatásokat javasolhatnak. Kulcsszabály: a Sprint Review a termékről szól, nem a folyamatról. Azt mutatjuk meg, mi valósult meg, nem azt, hogyan csináltuk.

Sprint Retrospective — a csapat belső megbeszélése az elmúlt sprint elemzésére. Formátum: Start Doing (mit kezdjünk el csinálni), Stop Doing (mit hagyjunk abba), Continue Doing (mit folytassunk). Időtartam — 1,5 óra egy 2 hetes sprint esetén. A Retrospective egy biztonságos tér a problémák megbeszélésére. Szabály: a Retro-ban nem beszélünk meg technikai részleteket (erre technikai megbeszélések vannak). Csak a folyamat, kommunikáció, eszközök, kultúra. A Scrum Master facilitálja a megbeszélést és biztosítja, hogy minden résztvevő elmondja a véleményét.

A Retrospective eredménye — 1-3 fejlesztés a következő sprintre. Ha a csapat azonosította a „Kódáttekintés túl hosszú” problémát — action item: „Állítson be SLA-t az áttekintésre — 4 óra. Ha az áttekintés nem történik meg időben — a fejlesztő emlékeztet Slacken”. Az Action Items-nek konkrétnak, mérhetőnek és egy adott személyhez rendeltnek kell lennie. Az Atlassian (2025) szerint a Retro action item-jeiket végrehajtó csapatok 15-25%-kal javítják a velocity-t 3-4 sprint alatt. Akik nem hajtják végre — helyben járnak.

Hogyan válasszuk ki a sprint időtartamát

2 hét — standard mobilfejlesztésben. Optimális egyensúly a kiszámíthatóság és rugalmasság között. Elegendő: megtervezni, 3-5 közepes funkciót megvalósítani, tesztelni, eredményt mutatni. 1 hét — magas folyamatérettséggel és CI/CD-vel rendelkező csapatok számára. Gyors döntéseket, minimális bürokratizmust igényel. Alkalmas korai fázisban lévő startupok számára, ahol gyorsan kell kísérletezni. Hátrány: magas túlterhelés a rituálék miatt (minden héten Planning + Review + Retro = 7,5 óra).

3-4 hét — összetett projektekhez, hardver-integrációval (wearables, IoT, BLE eszközök), hosszú áruház-moderációval vagy nagy migrációkkal (pl. váltás RxJava-ról Coroutines-re). A hosszú sprintek több időt adnak a tesztelésre, de növelik a „vízesés hatás” kockázatát — a csapat elveszíti az Agile rugalmasságot. A Scrum Guide ajánlása: ne haladja meg az 1 hónapot. Ha a sprint hosszabb — a Review túl sok kontextust fog tartalmazni, az érdekelt felek nem tudnak minőségi visszajelzést adni.

A sprintek tipikus problémái

1. probléma: Scope Creep. A sprint közepén a Product Owner hozzáad egy új „sürgős és fontos” feladatot. A csapat beleegyezik — és a sprint meghiúsul. Megoldás: a Sprint Goal szerződés. Bármilyen változtatás a Sprint Goal felülvizsgálatát igényli, és ez csak vészhelyzet esetén lehetséges. Az új feladat a Product Backlog-ba és a következő sprintbe kerül. Ha a feladat tényleg kritikus — a régi Sprint Goal-t törlök, a sprintet újratervezik, de ez kivétel, nem gyakorlat. A scope creep gyakorisága több mint 1 alkalom 3 sprint alatt — gyenge Product Owner jele.

2. probléma: Befejezetlen feladatok. A sprint végén a feladatok 50%-a In Progress, 20%-a Review, csak 30%-a Done. Okok: kapacitás túlbecslése, komplexitás alábecslése, nem tervezett hibák. Megoldás: elemezzük az okot a Retro-ban. Ha rendszeresen nem fértek bele — ne növeljék a feladatok számát a Planning-ben, hanem csökkentsék. A 20%-kal kevesebb feladatot vállaló csapatok magasabb befejezési arányt mutatnak (50-60% helyett 80%+). Ellenőrző lista a Planning-hez: minden feladathoz ellenőrizze az Acceptance Criteria-t, Definition of Ready-t és a más feladatoktól való függőségeket.

3. probléma: Formális Retro. A csapat látszatból tart Retro-t — 15 perc, általános frázisok, action items nélkül. Megoldás: változtassa meg minden Retro formátumát. Módszerek: Sailboat (mi lassít, mi gyorsít), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Rendeljen action items-et határidővel és felelőssel. A következő Retro elején ellenőrizze az előző action items végrehajtását. Az Atlassian (2025) szerint a különböző Retro formátumokat használó csapatok 50%-kal több hasznos felismerést generálnak.