Sprint w Scrumie to ograniczony czasowo cykl pracy trwający maksymalnie jeden miesiąc, podczas którego Zespół Scrumowy tworzy użyteczny przyrost produktu. Jest „sercem Scruma”, ponieważ zapewnia stały rytm inspekcji, uzyskiwania informacji zwrotnej i dostosowywania dalszych działań.
Czym jest Sprint w Scrumie?
W Scrum Guide Sprint został opisany jako time-box, czyli z góry ustalone ograniczenie czasowe. Może trwać od kilku dni do maksymalnie czterech tygodni. W tym czasie zespół koncentruje się na osiągnięciu Celu Sprintu i stworzeniu przyrostu produktu zgodnego z Definition of Done.
Przyrost nie jest jedynie zbiorem rozpoczętych zadań. Powinien przedstawiać działającą, użyteczną część produktu, którą można ocenić i potencjalnie udostępnić użytkownikom. Nie oznacza to obowiązku wdrożenia po każdym Sprincie, ale oznacza gotowość techniczną i jakościową do takiego kroku.
Rytm Sprintów wspiera empiryczne podejście Scruma. Zespół nie zakłada, że początkowy plan pozostanie niezmienny. Regularnie sprawdza stan produktu i sposób pracy, a następnie wprowadza korekty. Sprint nie jest więc miniaturowym projektem realizowanym według sztywnego harmonogramu, lecz powtarzalną pętlą uczenia się i dostarczania wartości.
Od wersji Scrum Guide z 2020 roku większy nacisk położono na dostarczanie wartości oraz na relację między Celem Sprintu a Celem Produktu. W starszej terminologii częściej mówiono o „potencjalnie wydawalnym przyroście”. Sens pozostał podobny: rezultat Sprintu ma być ukończony, użyteczny i zgodny z uzgodnionym standardem jakości.
Jak przebiega Sprint?
Jeden Sprint płynnie przechodzi w następny. Jego cykl obejmuje planowanie, realizację pracy, sprawdzenie przyrostu oraz doskonalenie sposobu działania zespołu:
- Sprint Planning – zespół ustala, jaki Cel Sprintu chce osiągnąć, które elementy Product Backlogu mogą w tym pomóc oraz jak zamierza wykonać tę pracę. Wynikiem jest Sprint Backlog, czyli Cel Sprintu, wybrane elementy backlogu i plan ich realizacji.
- Praca nad przyrostem – Deweloperzy wykonują zadania, doprecyzowują szczegóły i reagują na informacje pojawiające się w trakcie pracy. Daily Scrum pomaga sprawdzić postęp w kierunku Celu Sprintu oraz zaplanować najbliższe działania.
- Sprint Review – zespół wraz z interesariuszami ocenia przyrost i rozmawia o dalszym kierunku rozwoju produktu. To nie powinno być wyłącznie formalne demo, lecz wspólna inspekcja tego, co powstało i czego potrzebuje produkt.
- Sprint Retrospective – Zespół Scrumowy analizuje współpracę, proces, narzędzia i jakość pracy. Następnie wybiera usprawnienia, które może zastosować w kolejnym Sprincie.
Wydarzenia nie są niezależnymi spotkaniami. Planowanie wyznacza kierunek, codzienna synchronizacja pomaga go utrzymać, Review dostarcza informacji o produkcie, a Retrospective pozwala poprawić sposób pracy. Refinement Product Backlogu może odbywać się w trakcie Sprintu, jeśli pomaga przygotować przyszłe elementy, ale nie jest osobnym wydarzeniem Scrumowym.
Jak wybrać długość Sprintu?
Scrum Guide wyznacza górną granicę, ale nie wskazuje jednej idealnej długości. Najczęściej spotyka się Sprinty jedno- lub dwutygodniowe. Czterotygodniowy cykl daje więcej czasu na większe przyrosty, lecz opóźnia informację zwrotną. Krótszy cykl szybciej ujawnia problemy, ale zwiększa częstotliwość planowania, Review i Retrospective.
Porównanie najczęściej stosowanych wariantów wygląda następująco:
| Długość | Pętla zwrotna | Narzut planowania | Zalecany kontekst |
|---|---|---|---|
| 1 tydzień | Najczęstsza, szybkie sprawdzanie kierunku | Relatywnie wysoki, bo wydarzenia odbywają się często | Zmienne wymagania, praca blisko klientów, małe przyrosty |
| 2 tygodnie | Częsta i wystarczająco szybka dla większości zespołów | Umiarkowany | Uniwersalny punkt wyjścia dla nowych zespołów |
| 4 tygodnie | Najrzadsza, ryzyko późnego wykrycia problemów | Niższy w przeliczeniu na miesiąc, ale planowanie jest bardziej obciążające | Stabilne wymagania i przyrosty wymagające więcej czasu |
Długość warto dobrać na podstawie potrzeby uzyskiwania informacji zwrotnej, stabilności wymagań, wielkości przyrostów i możliwości zespołu. Jeśli zespół regularnie nie kończy użytecznego przyrostu, dłuższy Sprint może dać mu więcej przestrzeni, ale może też ukryć problemy z dzieleniem pracy. Jeżeli praca zamienia się w osobne etapy analizy, programowania i testów, krótszy Sprint może szybciej wymusić integrację.
Po wyborze długość powinna pozostać stała. Nie należy skracać Sprintu tylko dlatego, że zespół zakończył zaplanowane elementy, ani wydłużać go, aby „dowieźć” zaległą pracę. Stały rytm ułatwia przewidywanie, porównywanie wyników i planowanie kolejnych iteracji. Wiele zespołów zaczyna od dwóch tygodni, a później zmienia tę wartość na podstawie obserwacji.
Jak zarządzać Celem Sprintu i zakresem?
Cel Sprintu jest punktem odniesienia dla decyzji podejmowanych w trakcie iteracji. Nie opisuje każdej czynności, lecz wyjaśnia, po co zespół wykonuje wybraną pracę. Elementy Sprint Backlogu mogą zostać doprecyzowane, a plan może się zmienić, gdy pojawi się nowa wiedza. Zmiany nie powinny jednak zagrażać Celowi Sprintu ani obniżać jakości przyrostu.
Jeśli nowa potrzeba jest związana z przyjętym celem, Deweloperzy i Product Owner mogą uzgodnić zmianę zakresu. Zwykle oznacza to dodanie jednego elementu i usunięcie innego, ponieważ czas oraz możliwości zespołu są ograniczone. Wprowadzanie kolejnych niezależnych tematów tylko dlatego, że pojawiły się „przy okazji”, prowadzi do rozmycia celu.
Przed rozpoczęciem warto sprawdzić gotowość Sprintu. Pomocne pytania obejmują:
- Czy Cel Sprintu jest zrozumiały i wskazuje wartość, którą zespół chce dostarczyć?
- Czy Product Backlog jest uporządkowany, a najważniejsze zależności zostały rozpoznane?
- Czy zespół ma wystarczającą wiedzę i dostęp do osób potrzebnych do wykonania pracy?
- Czy wszyscy znają Definition of Done i rozumieją, co oznacza ukończenie elementu?
- Czy plan uwzględnia urlopy, inne obowiązki oraz ryzyka mogące ograniczyć dostępność zespołu?
Definition of Done chroni jakość przyrostu. Element niespełniający tego standardu nie staje się ukończony tylko dlatego, że minął koniec Sprintu. Nie można też poświęcać testów, bezpieczeństwa czy prac koniecznych do utrzymania produktu w imię większej liczby zamkniętych zadań.
Co zrobić, gdy Sprint traci sens?
Anulowanie Sprintu jest wyjątkową decyzją. W Scrum Guide 2020 Product Owner może anulować Sprint, jeśli jego Cel staje się nieaktualny. Taka sytuacja powinna wynikać z istotnej zmiany rzeczywistości, a nie z pojedynczego opóźnienia lub tego, że część pracy okazała się trudniejsza.
Po anulowaniu ukończone elementy zgodne z Definition of Done mogą zostać wykorzystane. Nieukończone elementy są ponownie oceniane i trafiają do Product Backlogu, gdzie Product Owner decyduje o ich dalszym priorytecie. Jeśli Sprint jest często przerywany albo zespół regularnie nie osiąga celu, problemu należy szukać w planowaniu, zależnościach, jakości lub zbyt szerokim zakresie.
Na jakie błędy uważać?
Nazwa „Sprint” może sugerować krótki, wyczerpujący wysiłek. W Scrumie chodzi jednak o tempo, które można utrzymać przez wiele kolejnych iteracji. Zespół powinien pracować bardziej jak podczas spokojnego biegu niż jednorazowego zrywu. Najczęstsze pułapki to:
- Pogoń za Velocity – traktowanie liczby punktów jako celu prowadzi do zawyżania estymacji i pomijania jakości. Velocity może pomóc w prognozowaniu, ale nie jest miarą wartości ani indywidualnej wydajności.
- Rozrost zakresu – dokładanie nowych tematów bez sprawdzenia wpływu na Cel Sprintu utrudnia koncentrację i zwiększa ryzyko niedokończenia pracy.
- Ignorowanie długu technicznego – odkładanie napraw, testów i prac utrzymaniowych może chwilowo zwiększyć liczbę funkcji, lecz później spowalnia rozwój i obniża stabilność produktu.
- Nierealne zobowiązania – planowanie na podstawie najlepszego możliwego scenariusza zamiast rzeczywistej dostępności zespołu kończy się presją i pracą po godzinach.
- Ciągłe zmienianie długości Sprintu – niestabilna kadencja utrudnia ocenę postępu i sprawia, że dane z poprzednich iteracji tracą wartość porównawczą.
Gdy kilka zespołów pracuje nad jednym produktem, ich rytm powinien umożliwiać wspólną inspekcję przyrostu. Nie muszą mieć identycznych Sprintów w każdej sytuacji, ale różne kadencje nie powinny utrudniać wspólnego Review i planowania zależności.
Dobrze zaprojektowany Sprint nie polega na wykonaniu jak największej liczby zadań. Jego miarą jest dostarczenie wartości zgodnej z Celem Sprintu, zachowanie jakości i zdobycie wiedzy potrzebnej do podjęcia lepszych decyzji w następnym cyklu.
