Sprint jest jednym z pięciu zdarzeń scrumowych zdefiniowanych w Scrum Guide. Stanowi ramę, time-box, w którym mieszczą się pozostałe cztery zdarzenia scrumowe oraz praca wytwórcza. Po zakończeniu jednego Sprintu rozpoczyna się kolejny, no chyba, że Product Owner zdecydował się zakończyć dalszy rozwój i utrzymanie produktu. To tak po krótce, aby nie przepisywać definicji ze Scrum Guide. Niby wszystko oczywiste i jasne, tylko po co zdefiniowano Sprinty?
Przede wszystkim stosowanie Sprintów powoduje obniżenie złożoności. Dzieje się to poprzez redukcję zmiennych wpływających na pracę zespołu scrumowego. Wspierając się diagramem Stacego, zmienne te, można podzielić na trzy obszary: zakres wymagań funkcjonalnych, wykorzystywana technologia oraz aspekt ludzki.
Zakres wymagań zostaje zredukowany, gdyż wspólnie ustalony Cel Sprintu pozostaje niezmienny do końca time-boxa. Zmniejsza się zatem ilość niewiadomych odnośnie tego co powinien zawierać Inkrement oraz jaki jest wymagany poziom jakości na koniec Sprintu. Lista czynności do wykonania jest znana, przynajmniej w większości i jeśli ulega zmianom to raczej niewielkim. Choć to nie musi być regułą. Najważniejszy jest niezmienny Cel.
Znany cel oraz zakres prac do realizacji to również znana technologia, z której będziemy korzystać. Wszystko o czym wiemy, że wystąpi redukuje złożoność. Możemy się na to przygotować lub też skorzystać z wcześniej ustalonych procedur działania i dobrych praktyk.
Podobnie jest w przypadku aspektu ludzkiego. Nieprzewidywalność w tym obszarze i jej wpływ na złożoność jest zredukowana chociażby poprzez ograniczenie ilości spotkań. Prawdopodobieństwo nieobecności członka zespołu też jest mniejsze jeśli weźmiemy pod uwagę jeden Sprint, a nie na przykład cały rok. Nie pokuszę się o wymienienie wszystkich możliwych ewentualności, gdyż jest to niemożliwe. Jesteśmy ludźmi i nasza kreatywność nie zna granic… oprócz granic wyznaczanych przez czas trwania Sprintu.
Ponieważ time-box, jakim jest Sprint, jest specyficzny i nie może zostać skrócony to wiadomo dokładnie na kiedy najpóźniej powinien być gotowy działający, zintegrowany i przetestowany Inkrement. Stałej wielkości iteracje zwiększają również transparentność i tym samym wspierają empiryzm. Gdybyśmy często zmieniali długość Sprintu lub też kończyli go przed czasem to wyciągnięcie wniosków byłoby utrudnione. Ciężko na przykład jednoznacznie stwierdzić czy zmiana jakiejś metryki w Sprincie została spowodowana wdrożeniem usprawnia czy też zmianą długości time-boxa. Właśnie dzięki temu, że możemy się uczyć na podstawie tego co i jak wykonujemy, możemy spodziewać się wzrostu wydajności i produktywności.
Ograniczenie prac nad produktem, do nie więcej niż jednego miesiąca, zmniejsza ryzyko sponsora projektu. Jest ono limitowane do jednego Sprintu. Po każdej iteracji otrzymuje on produkt gotowy do użycia, być może jeszcze niedoskonały, aczkolwiek ukończony w założonym zakresie. Znany jest również poziom jakości wytworzonego Inkrementu. Posiadając, co Sprint, nowy i używalny Inkrement możliwe jest szybkie i czeste zbieranie informacji zwrotnej. Możemy weryfikować dzięki temu nasze założenia biznesowe w myśl strategii „fail fast”. Dokonując inspekcji rezultatów podczas Sprint Review podejmujemy decyzje w oparciu o fakty, gdyż możemy zobaczyć działający Produkt. Możemy podjąć decyzję o dalszym kontynuowaniu prac lub też zmianie kierunku działań i wykonać pivot.
Sprinty wspomagają również budowę zaufania, gdyż dają okazję do częstego kontaktu. Za każdym razem, kiedy inwestor, szef lub sponsor projektu podejmuje decyzję o finansowaniu prac nad produktem jego cierpliwość i zaufanie są wystawione na próbę. Inkrementalny mechanizm jaki wprowadzają Sprinty sprawia, że próba ta jest łatwiejsza do zniesienia. Zaufanie pomiędzy przysłowiowym biznesem, a przysłowiowym IT wzrasta za każdym razem, kiedy po Sprincie można zobaczyć postęp w rozwoju produktu w postaci działającego oprogramowania. Steven Covey napisał kiedyś, że brak zaufania to olbrzymi podatek, który płacimy. Każdy, kto prowadzi biznes, chce płacić jak najmniejsze podatki.
Nieodłącznym elementem Sprintu jest Cel Sprintu. Powoduje on zwiększenie skupienia w Zespole Deweloperskim. Większe skupienie to większa produktywność. Cel Sprintu, tak samo jak znana z Toyota Production System zasada „stop starting start finishing”, promuje kończenie zadań zamiast posiadania wielu otwartych. Sprinty są po to, aby coś ukończyć.
Time-box wyznaczany przez Sprint oraz jego część składowa jaką jest Cel Sprintu są to dwa z trzech czynników potrzebnych do zaistnienia samo-organizacji w zespole. Bez niej, nie sposób rozwiązywać złożonych problemów adaptacyjnych (ang. complex adaptive problems). A do tego właśnie został zdefiniowany Scrum.
Po to są nam potrzebne Sprinty. O tym jak ustalić długość Sprintu, Sprincie Zero i innych dysfunkcjach napiszę w kolejnych postach.