Daily i stand-up — co to jest, zasady codziennego spotkania i korzyści

Czym jest daily i stand-up?

Daily Standup (codzienny stand-up, daily) — krótkie spotkanie zespołu Scrum, przeprowadzane o tej samej porze i w tym samym miejscu każdego dnia roboczego. Timebox — 15 minut. Występuje pod różnymi nazwami: Daily Scrum (w Scrum Guide), poranna synchronizacja, morning circle, daily. Celem jest synchronizacja zespołu, identyfikacja blokerów i skorygowanie planów na dzień. Daily to nie raport dla menedżera, ale narzędzie samoorganizacji zespołu. Zespół decyduje, jak ustrukturyzować spotkanie, a nie menedżer.

Pochodzenie terminu „stand-up„ — od praktyki stania podczas spotkania w dosłownym sensie: uczestnicy zbierają się przy tablicy i nie siadają. To tworzy poczucie tymczasowości — nikt nie chce stać dłużej niż 15 minut. Fizyczny stand-up wciąż jest używany w 60% zespołów (według danych Scrum.org 2025), reszta przeszła na format zdalny przez Zoom, Slack Huddle lub Teams. W formacie zdalnym ważne jest zachowanie dyscypliny: włączone kamery, brak wielozadaniowości, gotowość do wcześniejszego przemyślenia odpowiedzi.

Scrum Guide 2025 określa Daily Scrum jako wydarzenie dla Developers (programistów). Product Owner i Scrum Master mogą uczestniczyć, ale nie muszą. Jeśli PO lub SM uczestniczą — nie kierują spotkaniem. Zespół sam wybiera strukturę: klasyczne trzy pytania lub obchód tablicy (board walk). Kluczowe: daily dotyczy inspekcji postępu w kierunku Sprint Goal, a nie statusu każdego taska. Jeśli spotkanie zamienia się w wyliczanie tasków z tablicy — zespół stracił focus na Sprint Goal.

Trzy pytania Daily Standup

Pytanie 1: „Co zrobiłem wczoraj, aby osiągnąć Sprint Goal?„ — krótkie zestawienie ukończonych zadań. Nie „pracowałem nad APP-123„, a „skończyłem ekran logowania, PR wysłany do review„. Sformułowanie „aby osiągnąć Sprint Goal„ nie jest przypadkowe — łączy codzienną pracę z ogólnym celem sprintu. Jeśli programista nie widzi związku swojego zadania z Sprint Goal — to sygnał, że zadanie nie jest potrzebne w bieżącym sprincie. W mobilnym developmentcie wczorajszy rezultat to nie tylko kod, ale także testy, dokumentacja, konfiguracja CI/CD.

Pytanie 2: „Co planuję zrobić dzisiaj, aby osiągnąć Sprint Goal?„ — plan na bieżący dzień. Nie więcej niż 2-3 punkty. Programista może powiedzieć: „Dzisiaj skończę ViewModel dla ekranu profilu, napiszę testy jednostkowe, zbuduję aplikację na prawdziwym urządzeniu„. Jeśli plan pokrywa się z tym, co było „wczoraj„ — to sygnał, że zadanie jest zbyt duże i wymaga dekompozycji. Zasada dwóch dni: jeśli zadanie nie zostało ukończone w ciągu 2 dni pracy — należy je podzielić na podzadania, w przeciwnym razie utknie w In Progress na tygodnie.

Pytanie 3: „Jakie blokery utrudniają mój postęp?„ — najważniejsze pytanie. Bloker to coś, czego programista nie może rozwiązać sam: czeka na review (jeśli SLA review wyczerpany), nie działa emulator, niegotowe API, potrzebny dostęp do repozytorium. Ważne: bloker powinien zostać wymieniony, ale nie rozwiązany na daily. Po spotkaniu programista i Scrum Master / menedżer uzgadniają rozwiązanie blokera. Według danych Scrum.org (2025), 70% blokerów zespołu mobilnego związanych jest z: oczekiwaniem na review (30%), niedostępnością urządzeń testowych (20%), zależnościami od backendu (20%).

Jak prawidłowo prowadzić stand-up

Czas i miejsce. Daily odbywa się o tej samej porze każdego dnia — zazwyczaj na początku dnia roboczego (9:00-10:00). Dla zespołów rozproszonych wybiera się czas komfortowy dla wszystkich stref czasowych. Czas trwania — ściśle 15 minut. Stoper — obowiązkowy. Jeśli zespół się nie mieści — problem nie leży w daily, ale w procesie: albo jest zbyt wielu uczestników, albo zadania są omawiane zamiast tylko wymieniane. Zasada ping-ponga: każdy uczestnik mówi nie dłużej niż 60 sekund. Po odpowiedzi przekazuje głos następnej osobie.

Format „obchód tablicy„ (Board Walk). Alternatywa dla trzech pytań: zespół kolejno przesuwa zadania na tablicy Scrum, komentując zmiany. Programista bierze swój task z To Do, przenosi do In Progress i mówi: „Biorę APP-123 — ekran zamówienia, dodaję pole kodu promocyjnego„. Board Walk daje wizualne zrozumienie postępu i ujawnia „zapomniane„ taski — te, które wiszą bez ruchu 3+ dni. Board Walk jest preferowany dla zespołów rozproszonych z Jira/Linear — wszyscy widzą tablicę, a nie słuchają monologu.

Dla zespołów zdalnych: obowiązkowe włączone kamery — według danych Microsoft Research (2025), włączona kamera zwiększa zaangażowanie o 40%. Używajcie współdzielonego ekranu z tablicą zadań (Jira, Linear, Miro). Piszcie blokery na czacie — to tworzy pisemny zapis. Zachęcajcie do reakcji-emodżi (poza poleceniem użytkownika — emodżi nie są używane) — kciuk w górę dla wiadomości kolegi. Po daily — 2-3 minuty na „parking„ (parking lot): tematy wymagające osobnej dyskusji są zapisywane na liście follow-up spotkań. Kluczowa umiejętność Scrum Mastera: zatrzymać dyskusję na daily i przenieść ją do parking lot.

Typowe błędy przy prowadzeniu

Błąd 1: raport statusu dla menedżera. Programiści po kolei odczytują, co jest napisane w Jirze, menedżer zadaje pytania uzupełniające, spotkanie trwa 45 minut. Rozwiązanie: przypomnieć, że daily jest dla zespołu, a nie dla menedżera. Menedżer może sprawdzić status z tablicy. Jeśli menedżer zadaje pytania — przenieść je na 1:1. Zespół, który zamienił daily w raport, traci 2-3 godziny tygodniowo na wszystkich uczestników. Przy 8 programistach to 16-24 osobogodzin miesięcznie — utrata całego sprintu w roku.

Błąd 2: rozwiązywanie problemów na miejscu. Programista mówi „Mam buga z GRPC — projekt się nie buduje„, a cały zespół przez 20 minut dyskutuje nad rozwiązaniami. Rozwiązanie: zapisać bloker do parking lot, kontynuować daily. Po spotkaniu — zebrać zainteresowanych (programista + ktoś, kto może pomóc) na 10-minutową dyskusję. Według danych Basecamp (Shape Up), tylko 20% problemów wykrytych na daily wymaga dyskusji całego zespołu. Reszta jest rozwiązywana przez parę programistów w 10 minut.

Błąd 3: spóźnienia i nieobecności. Ktoś przychodzi 5 minut po rozpoczęciu — trzeba powtarzać. Rozwiązanie: ustalamy zasadę „daily zaczyna się punktualnie, spóźnialscy nie wchodzą„ lub „spóźnialski płaci karę„ (kawa dla zespołu). Jeszcze ostrzej: daily odbywa się o jednej porze, jeśli ktoś spóźnia się systematycznie — to kwestia jego dyscypliny, rozwiązywana na 1:1. Daily to synchronizacja dnia. Jeśli programista opuścił — nie jest zsynchronizowany i ryzykuje robienie nie tej pracy, której potrzebuje zespół.

Błąd 4: zbyt wielu uczestników. Zespół 15+ osób, każdy mówi po minucie — łącznie 20+ minut. Rozwiązanie: podzielcie zespół na podgrupy według feature'ów/modulów. Każda podgrupa prowadzi swoje daily (5-7 osób). Jeden przedstawiciel podgrupy może przyjść na wspólny cross-zespołowy stand-up (jeśli potrzebna jest synchronizacja między zespołami). Alternatywa: asynchroniczny stand-up przez Slack/GeekBot, gdzie każdy pisze co zrobił/planuje/blokery.

Asynchroniczny stand-up: alternatywy

Asynchroniczny stand-up — format, w którym uczestnicy piszą swoje odpowiedzi na czacie (Slack, Telegram, Teams) lub za pomocą specjalistycznego bota (GeekBot, Standuply, Status Hero) zamiast spotkania ustnego. Odpowiedni dla zespołów rozproszonych z różnicą stref czasowych 3+ godzin. Każdy uczestnik odpowiada na te same trzy pytania do określonego czasu (np. do 11:00). Bot zbiera odpowiedzi i publikuje podsumowanie na wspólnym kanale. Zalety: elastyczność, pisemny zapis, brak problemu spóźnień.

Wady formatu asynchronicznego: brak żywej komunikacji — tracone są sygnały niewerbalne, trudniej zidentyfikować blokery (programista może nie napisać o problemie). Bloker napisany na czacie może pozostać niezauważony do końca dnia. Według danych GitLab (2025), 40% zespołów, które przeszły na async standup, wróciło do ustnego w ciągu 3 miesięcy. Zalecenie: używajcie hybrydy — 3 dni ustnego stand-upu (pn, śr, pt), 2 dni asynchronicznego (wt, cz). Lub: ustny stand-up 1-2 razy w tygodniu, w pozostałe dni — asynchroniczny.

Narzędzia do asynchronicznego stand-upu: GeekBot (Slack) — zadaje trzy pytania, publikuje podsumowanie; Standuply — z integracją z Jira, automatycznym trackingiem; Status Hero — zbiera statusy i tworzy weekly report dla zarządu. Wybór narzędzia zależy od kultury zespołu: w startupach wystarczy bot na Slacku, w enterprise może być potrzebne Standuply z integracją w procesy korporacyjne. Ważna zasada: niezależnie od formatu, odpowiedzi powinny być widoczne dla całego zespołu, a nie tylko dla menedżera. Transparentność — kluczowa wartość Agile.

Specyfika daily dla zespołu mobilnego

Zespół mobilny na daily spotyka się ze specyficznymi blokerami. Główne: budowanie projektu w CI (Gradle build może trwać 20+ minut — jeśli się zepsuje, programista traci godzinę na diagnozę), oczekiwanie na TestFlight / Firebase App Distribution (publikacja builda dla testerów zajmuje 30-60 minut), problemy z emulatorami i symulatorami (Android Emulator wymaga KVM/HAXM, iOS Simulator tylko na Macu). Daily zespołu mobilnego powinno zawierać szybkie sprawdzenie statusu builda: „Czy build się kompiluje? Wszystkie testy zielone?„.

Dla projektów cross-platformowych (Flutter, React Native) daily może zawierać pytanie o stan współdzielonego kodu. Jeśli dwóch programistów jednocześnie edytuje ten sam plik Dart i jeden z nich wdraża zmiany — drugi będzie miał konflikty. Rada: używajcie Board Walk na tablicy z podziałem na platformy (Android / iOS / Shared). To pomaga zobaczyć, kto gdzie pracuje i czy zmiany się nie nakładają. Dla projektów z Flutter — tablica z kolumnami Platform Channel, BLoC/Cubit, UI, Tests.

Gotowość release'owa — kolejny specyficzny dla mobilnego developmentu punkt na daily. Na 3-5 dni przed release'm dodawajcie pytanie: „Czy build jest gotowy do release'u? Wszystkie metadane (ikony, zrzuty ekranu, opis) zaktualizowane?„. To zapobiega sytuacji, w której programiści kończą kod w dniu release'u, a budowanie i publikacja zajmują kolejne 3-4 godziny. Tracker release'owy — osobna tablica z checklistą: aktualizacja versionCode/versionName, sprawdzenie ProGuard, podpisanie AAB, wgranie do konsoli deweloperskiej, release notes.