Sprint w rozwoju mobilnym: istota, czas trwania i planowanie

Czym jest sprint w rozwoju?

Sprint — to przedział czasowy (timebox) o stałej długości, po którym zespół dostarcza gotowy do użycia przyrost produktu. Koncepcja sprintu jest podstawą Scrum, ale jest używana także w innych frameworkach Agile. W rozwoju mobilnym przyrost to build aplikacji, który można zainstalować na urządzeniu, przetestować i pokazać interesariuszom. Sprintu nie można przedłużyć — jeśli zadania nie są wykonane, przechodzą do następnego sprintu.

Kluczową cechą sprintu jest stały czas trwania. Zespół nie zmienia celu sprintu po zatwierdzeniu. To daje przewidywalność: interesariusze wiedzą, kiedy otrzymają rezultat. Wewnątrz sprintu zespół sam decyduje, jak rozdzielić pracę. Scrum Master chroni zespół przed zewnętrznymi ingerencjami — nowe zadania nie są dodawane do bieżącego sprintu. Według Scrum Guide 2025 to jedyny sposób na utrzymanie stabilnego tempa rozwoju (sustainable pace).

Sprint składa się z czterech obowiązkowych wydarzeń: Sprint Planning (planowanie), Daily Scrum (codzienna synchronizacja), Sprint Review (demonstracja wyniku), Sprint Retrospective (analiza procesu). Między nimi — główna praca: realizacja zadań, testowanie, code review. Czas trwania każdego wydarzenia jest proporcjonalny do długości sprintu: dla 2-tygodniowego sprintu Planning — 4 godziny, Review — 2 godziny, Retro — 1.5 godziny, Daily — 15 minut. Łącznie rytuały zajmują około 8 godzin na sprint — 10% czasu pracy zespołu.

Rytuały Scrum sprintu

Rytuały Scrum (ceremonie/wydarzenia) — ustrukturyzowane spotkania zespołu w ramach sprintu. Sprint Planning — na początku, Daily Scrum — każdego dnia, Sprint Review i Retrospective — na końcu. Wszystkie wydarzenia mają timebox (ograniczenie czasowe). Scrum Master dba o przestrzeganie timeboxu i skupienia. W każdym rytuale uczestniczy cały zespół Scrum: Product Owner, Scrum Master, programiści. Wyjątek — Daily Scrum (uczestniczą tylko programiści, PO i SM — opcjonalnie).

Związek rytuałów z etapami sprintu: Planning nadaje kierunek (co i jak robimy), Daily synchronizuje (kto co robi, jakie blokery), Review pokazuje wynik (co zrobiono, co nie), Retrospective ulepsza proces (jak zrobić następny sprint lepiej). Pominięcie retrospektywy — najczęstszy błąd zespołów: gdy terminy palą, poświęcają właśnie Retro. To prowadzi do stagnacji procesów i powtarzania tych samych błędów. Badanie Scrum.org (2025) pokazuje: zespoły przeprowadzające Retro co 2 tygodnie szybciej poprawiają velocity o 35%.

Sprint Planning: planowanie iteracji

Sprint Planning — spotkanie zespołu na początku sprintu, na którym określa się, co zostanie zrobione i jak. Product Owner przedstawia priorytetowe zadania z Product Backlog. Zespół ocenia capacity (dostępny czas z uwzględnieniem urlopów, spotkań, długu technicznego) i wybiera zadania, które może wykonać w sprincie. Rezultat Planning — Sprint Goal (cel sprintu) i Sprint Backlog (lista zadań). Sprint Goal formułuje się jako krótkie zdanie: „Zrealizować ekran zamówienia i integrację płatności przez BLIK“.

Velocity — prędkość zespołu, mierzona w story pointach na sprint. Średnia z 3-5 ostatnich sprintów. Według Scrum.org (2025), zespół 5 programistów mobilnych (3 Android + 2 iOS) ma velocity 25-40 SP na 2-tygodniowy sprint. Planning używa velocity jako górnej granicy — biorą o 10-15% mniej na nieprzewidziane zadania (code review, incydenty, pomoc innym zespołom). Capacity vs Velocity: capacity to „osobogodziny“, velocity to „story pointy“. Capacity uwzględnia urlopy, zwolnienia, spotkania. Typowy loss rate — 25-30% czasu pracy idzie na aktywności niekodowe.

Planowanie dzieli się na dwie części: „co“ (PO opowiada zadania, zespół doprecyzowuje) — 2 godziny, i „jak“ (zespół dekomponuje i ocenia) — 2 godziny. Dla projektów mobilnych w części „jak“ omawia się: kompatybilność z wersjami Android/iOS, potrzebę feature flag, wpływ na rozmiar APK/IPA, nowe uprawnienia. Technika Planning Poker jest używana do oceny: każdy programista podaje swoją ocenę w story pointach (1, 2, 3, 5, 8, 13). Rozbieżność > 2 jednostek — omawiają przyczyny. To ujawnia ukryte ryzyka na etapie planowania, a nie w środku sprintu.

Realizacja sprintu: Daily Standup i tracking

Daily Scrum (Standup) — codzienne 15-minutowe spotkanie synchronizacyjne zespołu. Każdy uczestnik odpowiada na trzy pytania: „Co zrobiłem wczoraj?“, „Co planuję dzisiaj?“, „Jakie blokery?“. Daily — nie raport statusu dla menedżera, ale narzędzie samoorganizacji zespołu. Jeśli podczas Daily okazuje się, że dwóch programistów pracuje nad tym samym zadaniem — to sygnał do reorganizacji. Ważne: Daily nie rozwiązuje problemów, a je identyfikuje — do rozwiązania zwołuje się osobne spotkanie po Daily.

Scrum Board (tablica sprintu) — wizualizacja Sprint Backlog. Kolumny: To Do / In Progress / In Review / Done. Każde zadanie przesuwa się po tablicy. Burndown Chart — wykres pozostałej pracy w dniach sprintu. Idealny burndown — linia prosta od total SP do 0. Rzeczywisty burndown — wykres schodkowy z uwzględnieniem zamykania zadań. Opadający burndown (poniżej idealnej linii) — spóźniamy się. Sygnał problemu: jeśli w połowie sprintu wykonano mniej niż 30% zadań — potrzebna korekta. Być może nie uwzględniono ryzyk lub zadania są przeszacowane.

Dla rozwoju mobilnego na tracking sprintu wpływają specyficzne czynniki: czas budowania (budowa projektu Android w CI może zajmować 30+ minut), oczekiwanie na moderację App Store / Google Play (jeśli trzeba wydać build testerom przez TestFlight), kompatybilność z różnymi urządzeniami (testowanie na 10+ modelach zajmuje czas). Rada: zaplanuj 1 dzień bufora na końcu sprintu na końcowe testy i budowanie wersji release. To zmniejsza ryzyko niedokończonego sprintu o 40% według Mind the Product (2025).

Sprint Review i Retrospective

Sprint Review — demonstracja przyrostu interesariuszom. Zespół pokazuje działający build aplikacji, a nie slajdy. Czas trwania — 2 godziny dla 2-tygodniowego sprintu. Product Owner sprawdza zgodność z Acceptance Criteria. Interesariusze udzielają informacji zwrotnej, która może wpłynąć na Product Backlog. Review — nie raport, a dialog: interesariusze mogą zadawać pytania i proponować zmiany. Kluczowa zasada: Sprint Review dotyczy produktu, a nie procesu. Pokazujemy, co się udało, a nie jak robiliśmy.

Sprint Retrospective — wewnętrzne spotkanie zespołu do analizy minionego sprintu. Format: Start Doing (co zacząć robić), Stop Doing (co przestać), Continue Doing (co kontynuować). Czas trwania — 1.5 godziny dla 2-tygodniowego sprintu. Retrospective to bezpieczna przestrzeń do omawiania problemów. Zasada: w Retro nie omawia się szczegółów technicznych (do tego są spotkania techniczne). Tylko proces, komunikacja, narzędzia, kultura. Scrum Master facylituje spotkanie i dba, aby każdy uczestnik się wypowiedział.

Rezultat Retrospective — 1-3 ulepszenia na następny sprint. Jeśli zespół zidentyfikował problem „Zbyt długi code review“ — action item: „Ustawić SLA na review — 4 godziny. Jeśli review nie zostało zrobione na czas — programista przypomina na Slacku“. Action Items powinny być konkretne, mierzalne i przypisane do konkretnej osoby. Według Atlassian (2025), zespoły, które wykonują swoje Retro action items, poprawiają velocity o 15-25% w ciągu 3-4 sprintów. Te, które nie wykonują — stoją w miejscu.

Jak wybrać czas trwania sprintu

2 tygodnie — standard dla rozwoju mobilnego. Optymalna równowaga między przewidywalnością a elastycznością. Wystarcza: zaplanować, zrealizować 3-5 średnich funkcji, przetestować, pokazać wynik. 1 tydzień — dla zespołów o wysokiej dojrzałości procesów i CI/CD. Wymaga szybkich decyzji, minimalnej biurokracji. Odpowiedni dla startupów na wczesnym etapie, gdy trzeba szybko eksperymentować. Wada: wysoki narzut na rytuały (co tydzień Planning + Review + Retro = 7.5 godziny).

3-4 tygodnie — dla złożonych projektów, gdzie integracja ze sprzętem (wearables, IoT, urządzenia BLE), długa moderacja sklepów lub duże migracje (np. przejście z RxJava na Coroutines). Długie sprinty dają więcej czasu na testowanie, ale zwiększają ryzyko „efektu wodospadu“ — zespół traci elastyczność Agile. Zalecenie Scrum Guide: nie przekraczaj 1 miesiąca. Jeśli sprint jest dłuższy — na Review będzie zbyt dużo kontekstu, interesariusze nie będą mogli udzielić wartościowej informacji zwrotnej.

Typowe problemy sprintów

Problem 1: Scope Creep. W środku sprintu Product Owner dodaje nowe zadanie „pilne i ważne“. Zespół się zgadza — i sprint jest nieudany. Rozwiązanie: Sprint Goal — kontrakt. Każda zmiana wymaga przejrzenia Sprint Goal, a to możliwe tylko w nagłych przypadkach. Nowe zadanie idzie do Product Backlog i do następnego sprintu. Jeśli zadanie jest naprawdę krytyczne — stary Sprint Goal jest anulowany, sprint jest planowany od nowa, ale to wyjątek, a nie praktyka. Częstotliwość scope creep większa niż 1 raz na 3 sprinty — oznaka słabego Product Ownera.

Problem 2: Niedokończone zadania. Pod koniec sprintu 50% zadań w In Progress, 20% w Review, tylko 30% Done. Przyczyny: przeszacowanie capacity, niedoszacowanie złożoności, nieplanowane błędy. Rozwiązanie: analizuj przyczynę na Retro. Jeśli systematycznie nie nadążacie — nie zwiększajcie liczby zadań w Planning, a zmniejszajcie. Zespoły, które biorą o 20% mniej zadań, pokazują wyższy procent ukończenia (80%+ wobec 50-60%). Lista kontrolna dla Planning: dla każdego zadania sprawdzić Acceptance Criteria, Definition of Ready i zależności od innych zadań.

Problem 3: Formalne Retro. Zespół przeprowadza Retro dla odhaczenia — 15 minut, ogólników, bez action items. Rozwiązanie: zmieniaj format każdego Retro. Metody: Sailboat (co hamuje, co przyspiesza), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Przydzielaj action items z terminem i osobą odpowiedzialną. Na początku następnego Retro sprawdzaj wykonanie poprzednich action items. Według Atlassian (2025), zespoły używające różnych formatów Retro generują o 50% więcej wartościowych wniosków.