Czym właściwie jest Sprint w Scrum?

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. Ale dość dygresjom, zajmijmy się Sprintem na poważnie!

 

Czym jest Sprint?

Zgodnie z definicją ze Scrum Guide, Sprint to ograniczenie czasowe mające pozwolić nam okiełznać skomplikowane problemy.

Ponieważ nie jesteśmy w stanie pracować nad wszystkim na raz, musimy zabierać się za poszczególne aspekty po kolei, etapami. Takie etapy to podstawa iteracyjnego wytwarzania oprogramowania. Przedstawicielem tego podejścia jest zaś Scrum, a Sprint to nic innego jak jedna iteracja.

“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

Sprint ma stałą długość i trwa od jednego do czterech tygodni. W ramach Sprintu powstaje Inkrement, czyli działający i wdrażalny przyrost oprogramowania. Każdy Sprint ma swój cel, który jest powodem tego całego zamieszania.

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 Inkrementu. Nic nie stoi jednak na przeszkodzie, żeby dowolnie zmieniać kurs pomiędzy Sprintami.

Warto także podkreślić, że 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.

Na Sprint składa się Sprint Planning, spotkania Daily Scrum, prace związane z wykonaniem przyrostu, Sprint Review i Sprint Retrospective. Od razu po skończeniu jednego Sprintu, rozpoczyna się następny. W Scrum nie ma miejsca na przestoje.

 

Biegniemy Sprint, ale celujemy w Maraton

W Sprintach bardzo często mierzymy Velocity czyli prędkość. Jest to liczba 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.

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.

To oczywiście spada na barki PO, bo to Product Owner jest odpowiedzialny za szacunki terminów, w jakich zrealizowane zostaną poszczególne funkcjonalności czy Epiki.

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ść.

 

Anulowanie Sprintu

Scrum Guide poświęcił aż cztery akapity sytuacji, w której Cel Sprintu przestał mieć sens. W takim przypadku Product Owner ma możliwość anulowania sprintu. Oczywiście na jego decyzję może wpłynąć zarówno Development Team, Scrum Master jak i chociażby interesariusz.

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

Osobiście spotkałem się z taką sytuacją raz, 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ć zaakceptowane i trafić na następne wdrożenie. Te, które nie miały tyle szczęścia, wracają do backlogu.

 

Optymalna długość sprintu

Istnieje bardzo prosty przepis na wyznaczenie idealnej długości Sprintu.

Kierując się ideą empiryzmu zacznijmy z dowolną wartością, np. dwa tygodnie i modyfikujmy ją w miarę potrzeb. W przypadku, gdy trudno nam jest ukończyć w tym czasie 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ć.

Warto też zaznaczyć, że zmiana długości Sprintu powinna być czymś rzadkim i dobrze uzasadnionym. Wszystkie zmiany najpierw powodują negatywną reakcję. Musimy poczekać na unormowanie się sytuacji, zanim będziemy mogli dokonać pomiarów efektywności naszych działań. Wprowadzając zmiany zbyt często, uzyskujemy chaos.

Pamiętajmy, że jeśli na projekcie mamy wiele zespołów, to 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. Dwa tygodnie i tydzień spełniają ten warunek, bo 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.

Wspominaliśmy już o tym na naszym kanale na YouTube, gdzie dyskutowaliśmy właśnie na temat długości Sprintu.

 

Więcej o Sprincie i Scrumie możecie dowiedzieć się na naszych szkoleniach Wprowadzenie do Scrum oraz Warsztaty Scrum.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: