.st0{fill:#FFFFFF;}

Czym właściwie jest Sprint w Scrum? 

 3 sierpnia, 2018

Tomasz Dzierżek

Sprint opisywany jest jako serce Scruma, które nadaje mu rytm. Nikt nie zdefiniował jeszcze, czym jest mózg Scruma, ale podejrzewamy, że będzie to Scrum Team. Dość dygresjom, zajmijmy się Sprintem na poważnie!

Proces Scrum został zaktualizowany wraz z opublikowaniem nowej wersji Scrum Guide w listopadzie 2020. Poniższy wpis uwzględnia zmiany wprowadzone w Podręczniku Scrum.

 

Czym jest Sprint?

Zgodnie z definicją ze Scrum Guide, Sprint to ograniczenie czasowe mające pozwolić nam „przekształcać pomysły w wartość”. Kiedyś powiedzielibyśmy, że ujarzmia i systematyzuje rozwiązywanie skomplikowanych problemów. Ale nie tylko o nie tu chodzi.

Sprint jest emanacją iteracyjnego wytwarzania oprogramowania (produktu). Ponieważ nie jesteśmy w stanie pracować nad wszystkim na raz, musimy zabierać się za poszczególne aspekty po kolei, etapami. Sprint to nic innego jak jedna iteracja. Jeżeli interesuje Cię, jak przebiega cały Proces Scrum, odpowiedź na pewno znajdziesz na naszym blogu. W tym tekście skupimy się na istocie Sprintu.

Przede wszystkim Sprint to jest jakiś wycinek czasu. Zaczyna się od spotkania Sprint Planning, zawiera wszystkie prace związane z wykonaniem przyrostu (w tym Daily i refinementy), a kończy się Sprint Review i Sprint RetrospectiveOd razu po skończeniu jednego Sprintu, rozpoczyna się następny. W Scrumie nie ma miejsca na przestoje.

„The heart of Scrum is a Sprint, a time-box of one month or less during which a „Done”, useable, and potentially releasable product Increment is created.” – Scrum Guide 2017

Jeżeli chodzi o produkt wytwarzany w Sprincie, to w Scrum Guide 2017 mówiliśmy o „gotowym, zgodnym z Definition of Done, używalnym i potencjalnie wdrażalnym Przyroście„. Od listopada 2020 raczej mówimy po prostu o „dostarczonej wartości„. Ale tak naprawdę, ciągle chodzi o to samo. W Sprincie powstaje coś, co możemy używać i jest użyteczne dla naszego klienta.

 

Cel Sprintu w Scrum

Sprint ma stałą długość i trwa od mniej niż miesiąc. Pod żadnym pozorem nie możemy go wydłużać „żeby coś dowieźć”, ani skracać „bo wyrobiliśmy się wcześniej”. Sprint to stały element naszego kalendarza i możemy je wyznaczyć na cały rok z góry.

Jakoś tak się przyjęło, że większość zespołów na całym świecie pracuje w dwutygodniowych iteracjach. Widzieliśmy zespoły pracujące w krótszych i dłuższych Sprintach, które też radziły sobie świetnie. Ważne jest, aby nie zmieniać co chwilę tej długości.

Równe tempo pracy jest nam potrzebne, żeby zwiększyć naszą przewidywalność. W końcu jeżeli czasami będziemy planować trzy tygodnie, a czasami cztery dni, to nikt nie będzie wiedział „ile możemy zrobić w jednym Sprincie„.

Dzięki działaniu w Sprintach mamy możliwość szybkiej odpowiedzi na zmieniającą się rzeczywistość. W Scrum Guide podkreślone jest, że niedopuszczalne są żadne zmiany, które wpłynęłyby na Cel Sprintu bądź jakość wytwarzanego produktu. Nic nie stoi jednak na przeszkodzie, żeby dowolnie zmieniać kurs pomiędzy Sprintami oraz uszczegóławiać nasz zakres wyrażony Backlogiem Sprintu.

W tym miejscu warto dodać, że Cel Sprintu to zawsze powinien być krok w kierunku aktualnego Celu Produktu. Więcej o tym drugim – w podlinkowanym tekście.

 

Przerwanie Sprintu

W „starym” Scrum Guide aż cztery akapity były poświęcone sytuacji, w której Cel Sprintu przestał mieć sens. Nowy streszcza tę sytuację w dwóch zdaniach. Jeżeli nasz Cel Sprintu się zdezaktualizował, Product Owner ma możliwość przerwania Sprintu. Oczywiście na jego decyzję może wpłynąć zarówno Scrum Master, Deweloper jak i chociażby interesariusz.

Przerwanie Sprintu to odpowiedź na wyjątkową sytuację, czarnego łabędzia, który totalnie zniweczył nasze plany. Musi to być coś niespotykanego, bo przecież Sprint nigdy nie trwa dłużej niż miesiąc, a zwykle – tak jak już powiedzieliśmy – dwa tygodnie.

Przez około dwadzieścia lat wspólnego doświadczenia scrumowego spotkaliśmy się z taką sytuacją dosłownie kilka razy. Najczęściej wtedy, gdy nagromadzenie błędów z ostatnio zrealizowanych User Stories przekroczyło granice przyzwoitości. Padła wtedy słuszna decyzja o anulowaniu Sprintu i doprowadzeniu produktu do stanu użyteczności przed jego dalszym rozwojem.

„Jeśli znalazłeś się w dołku, przede wszystkim przestań kopać.”

Warto też dodać, że nawet w przypadku anulowania Sprintu, wszystkie elementy ukończone zgodnie z Definition of Done mogą zostać oddane klientom do wykorzystania. Te, które nie miały tyle szczęścia, wracają do backlogu.

 

Praca nad Produktem w ramach Sprintu

Zakres Sprintu ulega doprecyzowaniu wraz z postępem prac. Zwykle w miarę wykonywania zadań zdefiniowanych na spotkaniu Sprint Planning dowiadujemy się o nich więcej. Czasami powoduje to zmiany w zakresie, które są dopuszczalne, o ile oczywiście nie zmieniamy celu.

Doprecyzowywanie bardzo często ma postać dodawania kolejnych zadań (tasków) do realizacji w bieżącym Sprincie. Wszystko jest ok tak długo, jak dotyczą one wymagań, które sobie zaplanowaliśmy na samym wstępie. Jeżeli chcemy podłączyć zmywarkę, a w trakcie montażu okazuje się, że trzeba wymienić kawałek rury i dorobić nowe kolanko, to trudno – cały czas dotyczy to tej samej pracy i tego samego celu. Gorzej, jeżeli wpadnie nam do głowy „przy okazji wymienić zlew”.

Nic ze Sprintu nie może wypaść, ani nic do Sprintu nie może dojść nowego bez zgody obu zainteresowanych odpowiedzialności. Mowa tu oczywiście o Deweloperach i Product Ownerze. Zwykle, jeżeli coś dorzucamy nowego, to coś innego musi wypaść. Tego nie unikniemy, bo czas nie jest z gumy. Możemy natomiast starać się uniknąć „mieszania zakresem Sprintu”.

Pamiętajmy też, że pewne prace w Sprincie dotyczą także tego, co znajduje się w Product Backlogu i nie jest jeszcze zaplanowane do realizacji. Mowa tutaj o Product Backlog Refinement, bez którego w ogóle Scrum nam nie zadziała. Ale ponieważ ten tekst już i tak jest wystarczająco długi, odłożymy ten temat na później.

 

Biegniemy Sprint, ale celujemy w Maraton

W Sprintach bardzo często mierzymy Velocity czyli prędkość. Jest to liczba zrealizowanych wymagań bądź suma ich rozmiarów wyrażonych np. w Story Points. Mówiąc inaczej „ile udało nam się dowieźć w ostatnim Sprincie”. Jak dobrze wiemy, skupienie się na prędkości, zamiast na jakości, powoduje dług technologiczny. Może też być przyczyną wypalenia i zwiększonej rotacji.

Agile Manifesto mówi wyraźnie – utrzymujmy zrównoważone tempo. Pracujmy w sposób jednostajny, bez zrywów tuż przed wdrożeniami. Co więcej, nie dociskajmy śruby, bo skończy się to tym, że najzdolniejsi odejdą, a to na pewno spowoduje problemy.

Nowy Scrum Guide dodaje do tego „Sprinty umożliwiają przewidywalność dzięki wymuszaniu inspekcji i adaptacji postępu w kierunku Celu Produktu przynajmniej raz w miesiącu kalendarzowym.” Przewidywalność jest w cenie. Jeżeli w jednym Sprincie realizujemy 3 wymagania, a w drugim 25, to jest to bardzo zły znak. Być może wymagania są nierównej wielkości, a być może jakieś wewnętrzne problemy spowodowały taką rozbieżność. Jednak nie da się ukryć, że planowanie długoterminowe w takiej sytuacji jest bardzo trudne.

O wiele lepiej jest mieć zespół, który co prawda nie pracuje aż tak „wydajnie”, jakby to robił gdyby wszyscy siedzieli w nadgodzinach, ale za to jest w stanie dane tempo utrzymać przez miesiące albo nawet i lata. Nie wspominając już o tym, że wydajność w przypadku „dociskania śruby” jest bardzo złudna.

Nie sugerujmy się nazwą „Sprint” i nie wykorzystujmy jej jako wymówki do narzucania nierealnego tempa pracy. Tutaj nie chodzi nam o krótki i wyczerpujący bieg, ani nawet o maraton. To jogging, który chcemy uprawiać w nieskończoność.

 

Optymalna długość Sprintu

Jeżeli nie mamy pomysłu na naszą długość Sprintu, to zacznijmy z dowolną wartością, np. dwa tygodnie i modyfikujmy ją w miarę potrzeb. Kierujmy się ideą empiryzmu i na podstawie doświadczeń decydujmy o tym, ile powinna trwać jedna iteracja.

W przypadku, gdy trudno nam jest ukończyć przyrost i dostarczyć rzeczywistą wartość – wydłużmy Sprint. Jeżeli zaś obserwujemy, że mamy tendencje do wpadania w waterfalla i dzielenia pracy na etapy analizy, dewelopmentu i testów – skróćmy ich długość.

„Jeżeli nie wiemy jak dobrać długość Sprintu, zacznijmy od dwóch tygodni.” – rekomendacja #białko

Weźmy też pod uwagę jak często potrzebujemy informacji zwrotnej od naszych klientów i użytkowników. Jest to szczególnie ważne dla projektów związanych z e-commerce, serwisami społecznościowymi czy aplikacjami mobilnymi. W tych samych obszarach niezwykle ważna będzie stabilność wymagań. Im częściej mogą ulegać one zmianie, tym krótszy powinien być Sprint. Ogólnie rzecz biorąc – im krótsze Sprinty, tym lepiej. Chyba, że ich długość zaczyna nam przeszkadzać.

 

Wiele zespołów, jeden Sprint

Jeśli mamy wiele zespołów pracujących wspólnie bądź nawet wpływających na swoje prace, to ich kadencja musi być jednostajna. Znaczy to tyle, że długości Sprintów zespołów pracujących nad jednym produktem muszą być swoimi wielokrotnościami.

Nie ma więc problemu, aby jeden zespół pracował w Sprintach dwutygodniowych, a inny w tygodniowych. W końcu wtedy co dwa tygodnie mamy okazję do wspólnego Sprint Review. Jeżeli jednak jeden zespół ma Sprinty trwające 5 dni roboczych, a drugi 8, to prosimy się o problemy.

Tu warto też dodać praktyczne porady – z naszego doświadczenia najlepiej pracuje się w Sprintach zaczynających się w poniedziałek, a kończących dwa tygodnie później w piątek. Nie jest to jednak żadna „dobra praktyka”, tylko nasze spostrzeżenie. Widzieliśmy też wiele zespołów, które zaczynają Sprinty np. w środę. Ważne jest, żeby nie było żadnych przerw pomiędzy końcem jednego, a początkiem następnego Sprintu. Gdy mija ostatnia minuta Retro, to następna minuta to pierwsza minuta Planowania. No chyba, że Retro kończymy w piątek o 17:00 – wtedy planowanie zaczynamy w kolejnej minucie roboczej, zapewne w Poniedziałek.

 

Wydaje nam się, że jak na definicję tego „Czym jest Sprint?” wystarczy. Więcej o samym Sprincie i Scrumie możecie dowiedzieć się na naszych szkoleniach Wprowadzenie do Scrum oraz Warsztaty Scrum.

Tomasz Dzierżek


21+ lat doświadczenia w IT, 13+ lat doświadczenia w Scrum i agile, PSM I-III, konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}