Sprint v mobilním vývoji: podstata, délka a plánování

Co je sprint ve vývoji?

Sprint — časový interval (timebox) s pevnou délkou, na jehož konci tým dodává k použití připravený přírůstek produktu. Koncept sprintu je základem Scrumu, ale používá se i v jiných Agile frameworkích. V mobilním vývoji je přírůstek build aplikace, který lze nainstalovat na zařízení, otestovat a ukázat zainteresovaným stranám. Sprint nelze prodloužit — pokud úkoly nejsou dokončeny, přecházejí do následujícího sprintu.

Klíčovou vlastností sprintu je pevná délka. Tým po schválení nemění cíl sprintu. To poskytuje předvídatelnost: zainteresované strany vědí, kdy obdrží výsledek. Uvnitř sprintu se tým sám rozhoduje, jak rozdělit práci. Scrum Master chrání tým před vnějšími zásahy — nové úkoly se nepřidávají do aktuálního sprintu. Podle Scrum Guide 2025 je to jediný způsob, jak udržet udržitelné tempo vývoje (sustainable pace).

Sprint se skládá ze čtyř povinných událostí: Sprint Planning (plánování), Daily Scrum (denní synchronizace), Sprint Review (demonstrace výsledku), Sprint Retrospective (analýza procesu). Mezi nimi — hlavní práce: provádění úkolů, testování, code review. Délka každé události je úměrná délce sprintu: pro dvoutýdenní sprint Planning — 4 hodiny, Review — 2 hodiny, Retro — 1,5 hodiny, Daily — 15 minut. Celkově rituály zabírají asi 8 hodin na sprint — 10 % pracovní doby týmu.

Scrum rituály sprintu

Scrum rituály (ceremoniály/události) — strukturovaná setkání týmu v rámci sprintu. Sprint Planning — na začátku, Daily Scrum — každý den, Sprint Review a Retrospective — na konci. Všechny události mají timebox (časové omezení). Scrum Master dohlíží na dodržování timeboxu a soustředění. Každého rituálu se účastní celý Scrum tým: Product Owner, Scrum Master, vývojáři. Výjimka — Daily Scrum (účastní se pouze vývojáři, PO a SM — volitelně).

Spojení rituálů s fázemi sprintu: Planning udává směr (co a jak děláme), Daily synchronizuje (kdo co dělá, jaké jsou překážky), Review ukazuje výsledek (co bylo uděláno, co ne), Retrospective zlepšuje proces (jak udělat následující sprint lépe). Vynechání retrospektivy — nejčastější chyba týmů: když termíny tlačí, obětují právě Retro. To vede ke stagnaci procesů a opakování stejných chyb. Výzkum Scrum.org (2025) ukazuje: týmy, které provádějí Retro každé 2 týdny, zlepšují velocity o 35 % rychleji.

Sprint Planning: plánování iterace

Sprint Planning — setkání týmu na začátku sprintu, kde se určuje, co bude provedeno a jak. Product Owner představuje prioritní úkoly z Product Backlogu. Tým hodnotí kapacitu (capacity — dostupný čas s ohledem na dovolené, schůzky, technický dluh) a vybírá úkoly, které může ve sprintu splnit. Výsledkem Planning je Sprint Goal (cíl sprintu) a Sprint Backlog (seznam úkolů). Sprint Goal je formulován jako krátká věta: „Realizovat objednávkovou obrazovku a integraci plateb“.

Velocity — rychlost týmu, měřená v story pointech na sprint. Průměr z posledních 3–5 sprintů. Podle Scrum.org (2025) má tým 5 mobilních vývojářů (3 Android + 2 iOS) velocity 25–40 SP na dvoutýdenní sprint. Planning používá velocity jako horní hranici — berou o 10–15 % méně na nepředvídané úkoly (code review, incidenty, pomoc jiným týmům). Capacity vs Velocity: capacity jsou „člověkohodiny“, velocity jsou „story pointy“. Capacity zohledňuje dovolené, nemoc, schůzky. Typická loss rate — 25–30 % pracovní doby jde na nekódové aktivity.

Plánování se dělí na dvě části: „co“ (PO popisuje úkoly, tým upřesňuje) — 2 hodiny, a „jak“ (tým dekomponuje a odhaduje) — 2 hodiny. U mobilních projektů se v části „jak“ diskutuje: kompatibilita s verzemi Android/iOS, potřeba feature flag, dopad na velikost APK/IPA, nová oprávnění. Technika Planning Poker se používá pro odhad: každý vývojář dává svůj odhad v story pointech (1, 2, 3, 5, 8, 13). Rozdíl větší než 2 jednotky — diskutují důvody. To odhaluje skrytá rizika ve fázi plánování, ne uprostřed sprintu.

Provádění sprintu: Daily Standup a sledování

Daily Scrum (Standup) — denní 15minutové setkání pro synchronizaci týmu. Každý účastník odpovídá na tři otázky: „Co jsem dělal včera?“, „Co plánuji dnes?“, „Jaké mám překážky?“. Daily není status report pro manažera, ale nástroj sebeorganizace týmu. Pokud se během Daily zjistí, že dva vývojáři pracují na stejném úkolu — je to signál k reorganizaci. Důležité: Daily neřeší problémy, ale identifikuje je — k řešení je po Daily svolána samostatná schůzka.

Scrum Board (sprint tabule) — vizualizace Sprint Backlogu. Sloupce: To Do / In Progress / In Review / Done. Každý úkol se pohybuje po tabuli. Burndown Chart — graf zbývající práce podle dní sprintu. Ideální burndown — přímka od total SP k 0. Skutečný burndown — stupňovitý graf zohledňující uzavírání úkolů. Klesající burndown (pod ideální přímkou) — zpožďujeme se. Signál problému: pokud je uprostřed sprintu dokončeno méně než 30 % úkolů — je třeba korekce. Možná nebyly zohledněny rizika nebo jsou úkoly nadhodnoceny.

Pro mobilní vývoj ovlivňují sledování sprintu specifické faktory: čas sestavení (build Android projektu v CI může trvat 30+ minut), čekání na moderaci App Store / Google Play (pokud je třeba doručit build testerům přes TestFlight), kompatibilita s různými zařízeními (testování na 10+ modelech zabírá čas). Rada: naplánujte 1 den rezervy na konci sprintu na závěrečné testování a sestavení release verze. To sníží riziko nedokončeného sprintu o 40 % podle Mind the Product (2025).

Sprint Review a Retrospective

Sprint Review — demonstrace přírůstku zainteresovaným stranám. Tým ukazuje fungující build aplikace, ne slajdy. Délka — 2 hodiny pro dvoutýdenní sprint. Product Owner kontroluje shodu s Acceptance Criteria. Zainteresované strany poskytují zpětnou vazbu, která může ovlivnit Product Backlog. Review není zpráva, ale dialog: zainteresované strany mohou klást otázky a navrhovat změny. Klíčové pravidlo: Sprint Review je o produktu, ne o procesu. Ukazujeme, čeho bylo dosaženo, ne jak jsme to dělali.

Sprint Retrospective — interní setkání týmu pro analýzu uplynulého sprintu. Formát: Start Doing (co začít dělat), Stop Doing (co přestat), Continue Doing (co pokračovat). Délka — 1,5 hodiny pro dvoutýdenní sprint. Retrospective je bezpečný prostor pro diskusi o problémech. Pravidlo: v Retro se neřeší technické detaily (k tomu jsou technické schůzky). Pouze proces, komunikace, nástroje, kultura. Scrum Master facilituje setkání a zajišťuje, aby se každý účastník vyjádřil.

Výsledek Retrospective — 1–3 zlepšení pro následující sprint. Pokud tým identifikoval problém „Code review je příliš dlouhé“ — action item: „Nastavte SLA na review — 4 hodiny. Pokud review není provedeno včas — vývojář připomene na Slacku“. Action Items musí být konkrétní, měřitelné a přidělené konkrétní osobě. Podle Atlassian (2025) týmy, které plní své Retro action items, zlepšují velocity o 15–25 % během 3–4 sprintů. Ty, které je neplní — šlapou na místě.

Jak zvolit délku sprintu

2 týdny — standard pro mobilní vývoj. Optimální rovnováha mezi předvídatelností a flexibilitou. Stačí: naplánovat, realizovat 3–5 středních funkcí, otestovat, ukázat výsledek. 1 týden — pro týmy s vysokou vyspělostí procesů a CI/CD. Vyžaduje rychlá rozhodnutí, minimální byrokracii. Vhodný pro startupy v rané fázi, které potřebují rychle experimentovat. Nevýhoda: vysoká režie na rituály (každý týden Planning + Review + Retro = 7,5 hodiny).

3–4 týdny — pro komplexní projekty s hardwarovou integrací (wearables, IoT, BLE zařízení), dlouhou moderací obchodů nebo velkými migracemi (např. přechod z RxJava na Coroutines). Dlouhé sprinty dávají více času na testování, ale zvyšují riziko „vodopádového efektu“ — tým ztrácí Agile flexibilitu. Doporučení Scrum Guide: nepřekračujte 1 měsíc. Pokud je sprint delší — na Review bude příliš mnoho kontextu, zainteresované strany nebudou moci poskytnout kvalitní zpětnou vazbu.

Typické problémy sprintů

Problém 1: Scope Creep. Uprostřed sprintu přidá Product Owner nový „nutný a důležitý“ úkol. Tým souhlasí — a sprint selže. Řešení: Sprint Goal je kontrakt. Jakákoli změna vyžaduje revizi Sprint Goal, a to je možné jen v naléhavých případech. Nový úkol jde do Product Backlogu a následujícího sprintu. Pokud je úkol skutečně kritický — starý Sprint Goal se zruší, sprint se přeplánuje, ale to je výjimka, ne praxe. Frekvence scope creep vyšší než 1× za 3 sprinty — známka slabého Product Ownera.

Problém 2: Nedokončené úkoly. Na konci sprintu je 50 % úkolů v In Progress, 20 % v Review, pouze 30 % Done. Příčiny: nadhodnocení kapacity, podhodnocení složitosti, neplánované chyby. Řešení: analyzujte příčinu na Retro. Pokud systematicky nestíháte — nezvyšujte počet úkolů v Planning, ale snižte. Týmy, které berou o 20 % méně úkolů, vykazují vyšší procento dokončení (80 %+ oproti 50–60 %). Kontrolní seznam pro Planning: u každého úkolu zkontrolujte Acceptance Criteria, Definition of Ready a závislosti na jiných úkolech.

Problém 3: Formální Retro. Tým dělá Retro pro forma — 15 minut, všeobecné fráze, bez action items. Řešení: měňte formát každého Retro. Metody: Sailboat (co brzdí, co zrychluje), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Přidělte action items s termínem a odpovědnou osobou. Na začátku následujícího Retro zkontrolujte splnění předchozích action items. Podle Atlassian (2025) týmy používající různé formáty Retro generují o 50 % více užitečných poznatků.