Daily a stand-up — co to je, pravidla denní schůzky a přínos

Co je daily a stand-up?

Daily Standup (denní stand-up, daily) — krátká schůzka Scrum týmu, konaná ve stejnou dobu a na stejném místě každý pracovní den. Timebox — 15 minut. Vyskytuje se pod různými názvy: Daily Scrum (v Scrum Guide), ranní synchronizace, morning circle, daily. Cílem je synchronizovat tým, identifikovat blokátory a upravit plány na den. Daily není hlášení pro manažera, ale nástroj sebeorganizace týmu. Tým rozhoduje, jak schůzku strukturovat, nikoli manažer.

Původ termínu „stand-up" — z praxe doslovného stání během schůzky: účastníci se shromáždí u tabule a nesednou si. To vytváří pocit dočasnosti — nikdo nechce stát déle než 15 minut. Fyzický stand-up se stále používá v 60% týmů (podle údajů Scrum.org 2025), zbytek přešel na vzdálený formát přes Zoom, Slack Huddle nebo Teams. Ve vzdáleném formátu je důležité udržovat disciplínu: zapnuté kamery, bez multitaskingu, připravenost předem promyslet odpovědi.

Scrum Guide 2025 definuje Daily Scrum jako událost pro Developers (vývojáře). Product Owner a Scrum Master mohou být přítomni, ale nejsou povinni. Pokud PO nebo SM jsou přítomni — neřídí schůzku. Tým si sám vybírá strukturu: klasické tři otázky nebo board walk. Klíčové: daily je o kontrole pokroku směrem k Sprint Goal, nikoli o stavu každého úkolu. Pokud se schůzka změní ve vyjmenovávání úkolů z tabule — tým ztratil zaměření na Sprint Goal.

Tři otázky Daily Standupu

Otázka 1: „Co jsem udělal včera pro dosažení Sprint Goal?" — stručný seznam dokončených úkolů. Ne „pracoval jsem na APP-123", ale „dokončil přihlašovací obrazovku, PR odeslán na review". Formulace „pro dosažení Sprint Goal" není náhodná — spojuje každodenní práci s obecným cílem sprintu. Pokud vývojář nevidí spojení svého úkolu s Sprint Goal — je to signál, že úkol není v aktuálním sprintu potřeba. V mobilním vývoji není včerejší výsledek jen kód, ale také testy, dokumentace, konfigurace CI/CD.

Otázka 2: „Co plánuji udělat dnes pro dosažení Sprint Goal?" — plán na aktuální den. Ne více než 2-3 body. Vývojář může říci: „Dnes dokončím ViewModel pro obrazovku profilu, napíšu unit testy, spustím build na reálném zařízení". Pokud se plán shoduje s tím, co bylo „včera" — je to signál, že úkol je příliš velký a je třeba ho rozložit. Pravidlo dvou dnů: pokud úkon není dokončen do 2 pracovních dnů — je třeba ho rozdělit na podúkoly, jinak uvízne v In Progress na týdny.

Otázka 3: „Jaké blokátory brání mému pokroku?" — nejdůležitější otázka. Blokátor je něco, co vývojář nemůže vyřešit sám: čeká na review (pokud vypršela SLA pro review), nefunguje emulátor, není připravené API, potřebuje přístup do repozitáře. Důležité: blokátor by měl být jmenován, ale ne řešen na daily. Po schůzce se vývojář a Scrum Master / manažer dohodnou na řešení blokátoru. Podle údajů Scrum.org (2025) je 70% blokátorů mobilního týmu spojeno s: čekáním na review (30%), nedostupností testovacích zařízení (20%), závislostmi na backendu (20%).

Jak správně vést stand-up

Čas a místo. Daily se koná ve stejnou dobu každý den — obvykle na začátku pracovního dne (9:00-10:00). Pro distribuované týmy se volí čas pohodlný pro všechna časová pásma. Délka — striktně 15 minut. Časovač — povinný. Pokud se tým nevejde — problém není v daily, ale v procesu: buď je příliš mnoho účastníků, nebo se úkoly diskutují místo pouhého jmenování. Pravidlo ping-pongu: každý účastník mluví nejvýše 60 sekund. Po odpovědi předá slovo dalšímu.

Formát „obchůzka tabule" (Board Walk). Alternativa ke třem otázkám: tým postupně přesouvá úkoly na Scrum tabuli a komentuje změny. Vývojář vezme svůj úkol z To Do, přesune do In Progress a řekne: „Beru APP-123 — obrazovku objednávky, přidávám pole pro promo kód". Board Walk poskytuje vizuální pochopení pokroku a odhaluje „zapomenuté" úkoly — ty, které stojí bez pohybu 3+ dny. Board Walk je preferovanější pro distribuované týmy s Jirou/Linear — všichni vidí tabuli, neposlouchají monolog.

Pro vzdálené týmy: povinně zapnuté kamery — podle údajů Microsoft Research (2025) zvyšuje zapnutá kamera zapojení o 40%. Používejte sdílenou obrazovku s tabulí úkolů (Jira, Linear, Miro). Pište blokátory do chatu — to vytváří písemný záznam. Podporujte reakční emodži (kromě příkazu uživatele — emodži se nepoužívají) — palec nahoru na zprávu kolegy. Po daily — 2-3 minuty na „parkování" (parking lot): témata vyžadující samostatnou diskusi se zapisují do seznamu follow-up schůzek. Klíčová dovednost Scrum Mastera: zastavit diskusi na daily a přesunout ji do parking lotu.

Typické chyby při vedení

Chyba 1: report stavu pro manažera. Vývojáři postupně čtou, co je napsáno v Jiře, manažer klade upřesňující otázky, schůzka trvá 45 minut. Řešení: připomeňte, že daily je pro tým, ne pro manažera. Manažer se může dozvědět stav z tabule. Pokud manažer klade otázky — přesuňte je na 1:1. Tým, který proměnil daily v report, ztrácí 2-3 hodiny týdně na všechny účastníky. Při 8 vývojářích je to 16-24 člověkohodin měsíčně — ztráta celého sprintu za rok.

Chyba 2: řešení problémů na místě. Vývojář řekne „Mám bug s GRPC — projekt se nesestaví" a celý tým 20 minut diskutuje možná řešení. Řešení: zapište blokátor do parking lotu, pokračujte v daily. Po schůzce — shromážděte zainteresované (vývojář + někdo, kdo může pomoci) na 10minutovou diskusi. Podle Basecamp (Shape Up) pouze 20% problémů objevených na daily vyžaduje diskusi celého týmu. Zbytek vyřeší pár vývojářů za 10 minut.

Chyba 3: zpoždění a absence. Někdo přijde 5 minut po začátku — musí se opakovat. Řešení: stanovíme pravidlo „daily začíná včas, zpozdilí nevstupují" nebo „zpozdilý platí pokutu" (káva pro tým). Ještě přísněji: daily se koná ve stejnou dobu, pokud někdo systematicky chodí pozdě — je to otázka jeho disciplíny, řeší se na 1:1. Daily je synchronizace dne. Pokud vývojář chyběl — není synchronizován a riskuje, že bude dělat práci, kterou tým nepotřebuje.

Chyba 4: příliš mnoho účastníků. Tým 15+ lidí, každý mluví minutu — celkem 20+ minut. Řešení: rozdělte tým do podskupin podle funkcí/modulů. Každá podskupina vede své vlastní daily (5-7 osob). Jeden zástupce z podskupiny může přijít na společný cross-týmový stand-up (pokud je potřeba synchronizace mezi týmy). Alternativa: asynchronní stand-up přes Slack/GeekBot, kde každý napíše, co udělal/plánuje/blokátory.

Asynchronní stand-up: alternativy

Asynchronní stand-up — formát, ve kterém účastníci píší své odpovědi do chatu (Slack, Telegram, Teams) nebo specializovaného bota (GeekBot, Standuply, Status Hero) namísto ústní schůzky. Vhodný pro distribuované týmy s rozdílem časových pásem 3+ hodiny. Každý účastník odpovídá na stejné tři otázky do určitého času (např. do 11:00). Bot shromáždí odpovědi a zveřejní souhrn na společném kanálu. Výhody: flexibilita, písemný záznam, žádný problém se zpožděním.

Nevýhody asynchronního formátu: chybí živá komunikace — ztrácej se neverbální signály, je obtížnější identifikovat blokátory (vývojář nemusí o problému napsat). Blokátor napsaný v chatu může zůstat nepovšimnutý do konce dne. Podle údajů GitLab (2025) se 40% týmů, které přešly na async stand-up, vrátilo k ústnímu během 3 měsíců. Doporučení: používejte hybrid — 3 dny ústní stand-up (po, st, pá), 2 dny asynchronní (út, čt). Nebo: ústní stand-up 1-2krát týdně, ve zbývajících dnech — asynchronní.

Nástroje pro asynchronní stand-up: GeekBot (Slack) — pokládá tři otázky, zveřejňuje souhrn; Standuply — s integrací s Jirou, automatickým sledováním; Status Hero — sbírá statusy a vytváří týdenní report pro management. Výběr nástroje závisí na kultuře týmu: ve startupech stačí bot ve Slacku, v enterprise může být potřeba Standuply s integrací do firemních procesů. Důležité pravidlo: bez ohledu na formát by odpovědi měly být viditelné pro celý tým, nejen pro manažera. Transparentnost — klíčová hodnota Agile.

Specifika daily pro mobilní tým

Mobilní tým na daily čelí specifickým blokátorům. Hlavní: sestavení projektu v CI (Gradle build může trvat 20+ minut — pokud se rozbije, vývojář ztrácí hodinu na zjištění), čekání na TestFlight / Firebase App Distribution (zveřejnění buildu pro testery trvá 30-60 minut), problémy s emulátory a simulátory (Android Emulator vyžaduje KVM/HAXM, iOS Simulator pouze na Macu). Daily mobilního týmu by mělo zahrnovat rychlou kontrolu stavu buildu: „Build se sestavuje? Všechny testy jsou zelené?"

Pro cross-platform projekty (Flutter, React Native) může daily zahrnovat otázku o stavu sdíleného kódu. Pokud dva vývojáři současně upravují stejný Dart soubor a jeden z nich sloučí změny — druhý bude mít konflikty. Rada: používejte Board Walk na tabuli s rozdělením podle platforem (Android / iOS / Shared). To pomáhá vidět, kdo kde pracuje a zda se změny překrývají. Pro projekty s Flutterem — tabule se sloupci Platform Channel, BLoC/Cubit, UI, Tests.

Připravenost na release — další specifický bod pro mobilní vývoj v daily. 3-5 dní před release přidejte otázku: „Je build připraven k release? Všechna metadata (ikony, snímky obrazovky, popis) jsou aktualizována?" Toto předchází situaci, kdy vývojáři dokončí kód v den release a sestavení a zveřejnění trvá další 3-4 hodiny. Release tracker — samostatná tabule s checklistem: aktualizace versionCode/versionName, kontrola ProGuard, podepsání AAB, nahrání do vývojářské konzole, release notes.