Sprint jest zdefiniowany w Scrum jako stały czas, podczas którego jest wykonywana cała praca związana z wytworzeniem Przyrostu (nowej wersji produktu). Innymi słowy Sprint jest kontenerem, wewnątrz którego znajdują się wszystkie zdarzenia Scrum oraz cała praca implementacyjna (developerska).

Kolejność zdarzeń w Sprincie jest ściśle określona, aby zapewnić możliwość zadziałania pętli sprawdzenia i dostosowania (ang. ispect & adapt) w procesie empirycznym:

• Sprint rozpoczyna się Planowaniem Sprintu (uwaga: w czasie Planowania Sprint już trwa).
• Po zakończeniu Planowania odbywa się praca developerska, a każdego dnia Developerzy spotykają się w ramach Daily Scruma.
• Również w czasie Sprintu, w wybranych przez Zespół momentach, odbywa się Pielęgnacja Backlogu Produktu.
• Praca developerska kończy się przed Przeglądem Sprintu, przed którym powstaje przynajmniej jeden Przyrost.
• Ostatnim zdarzeniem w Sprincie jest Retrospekcja Sprintu (uwaga: w czasie Retrospekcji Sprint wciąż trwa).

Pomiędzy Sprintami nie odbywają się żadne prace nad produktem – nie są zmieniane jego cechy lub funkcjonalności. Jeśli Planowanie Sprintu nie rozpoczyna się rankiem, a Retrospekcja Sprintu nie kończy dnia pracy, czas przed Planowaniem / po Retrospekcji może być użyty przez Zespół do dokonywania usprawnień, rozwiązywania błędów, Pielęgnacji Backlogu Produktu albo samorozwoju.

Sprint może mieć długość maksymalnie 1 miesiąca i jest wskazane, aby w obrębie jednego przedsięwzięcia długość sprintu pozostawała stała. O tym, jak długi powinien być Sprint konkretnego Zespołu, decydują dwa czynniki:

• Jakie często należy sprawdzać z interesariuszami i użytkownikami, czy budowany jest właściwy produkt – im większa zmienność potrzeb, rynku i technologii, im większe ryzyko pójścia w złą stronę, tym Sprint powinien być krótszy.
• Ile czasu potrzeba, aby wytworzyć wystarczająco dużo wartości, by uzasadniała ona realizację Sprintu – nie może on być zbyt krótki, zwłaszcza jeśli niektóre działania Developerów są długotrwałe z przyczyn od nich niezależnych.

Sprinty nie muszą rozpoczynać się w poniedziałki ani kończyć w piątki, nie muszą nawet być wielokrotnością tygodni (choć to zdecydowanie ułatwia ich organizację, bo poszczególne zdarzenia odbywają się wtedy zawsze w te same dni tygodnia). Jest też możliwe, by Sprint kończył się w tym samym dniu, w którym (po zakończeniu poprzedniego) rozpoczyna się kolejna iteracja.

Należy bardzo dokładnie i stanowczo przestrzegać ustalonej długości Sprintu, w szczególności nie wolno skracać ani wydłużać iteracji choćby o parę godzin. Celem takiego podejścia jest umożliwienie działania empiryzmu poprzez wyznaczenie stałego, obiektywnego interwału, po którym produkt jest poddawany sprawdzeniu (ang. inspect) i może nastąpić dostosowanie (ang. adapt). Co Sprint interesariusze poznają rzeczywisty stan produktu. Wyznaczają go wymagania, które Zespół całkowicie ukończył podczas ostatniego Sprintu.

Ponadto celem Sprintu o niezmiennej długości jest wytworzenie stałego rytmu pracy. Rytm ten będzie istotny nie tylko dla Zespołu, ale i dla całej organizacji. Wszyscy będą wiedzieć, że co dwa albo trzy tygodnie pojawia się nowa wersja produktu oraz rozpoczyna praca nad następną. Długość Sprintu ustala się podczas rozpoczynania pracy nad danym przedsięwzięciem, nie powinna być ona potem pochopnie zmieniana. Jeśli z jakichś powodów powodów zmiana jest konieczna, nie powinna ona dotyczyć jednego Sprintu, lecz winna być następnie stosowana przez dłuższy czas.

 

zmiana