Planowanie sprintu

Każdy sprint rozpoczyna się od spotkania zwanego planowaniem sprintu (Sprint Planning), podczas którego zespół deweloperski przedstawia prognozę jakie wymagania zaimplementuje w ciągu sprintu.

Każdy sprint rozpoczyna się od planowania sprintu. Jest to spotkanie, w którym bierze udział cały Zespół Scrum (a więc Product Owner, Scrum Master i Zespół Developerski). Jego celem

jest zastanowienie się co można zrobić w nadchodzącym sprincie, a także jak to zrobić. Produktem planowania jest backlog sprintu (Sprint Backlog) oraz cel sprintu (Sprint Goal).

Maksymalny czas trwania planowania to 8h dla sprintu miesięcznego, jest zalecane aby planowanie dla krótszych sprintów było odpowiednio krótsze. Dobry wskaźnik to max. 2h na tydzień sprintu.

By odpowiedzieć na pytanie „co można zrobić w tym sprincie”, Product Owner przedstawia backlog produktu w jego aktualnej kolejności, omawia jakie cele chciałby osiągnąć następną wersją produktu (inkrementem), oraz które wymagania powinny być zrealizowane, żeby osiągnąć ten cel. Zespół Scrum wspólnie dyskutuje i ustala zakres pracy. Zespół Developerski kolejno, od góry, analizuje wymagania z backlogu produktu, a następnie prognozuje ile z nich zrobi w najbliższym sprincie. O wymaganiach, które zmieściły się w tej prognozie, mówimy potocznie, że „zostały wzięte na sprint” albo „do sprintu”. Następnie, cały Zespół Scrum wypracowuje cel sprintu (Sprint Goal). Cel sprintu zostanie osiągnięty poprzez implementację wybranych wymagań z backlogu produktu, jest on zarazem celem do osiągnięcia jak i uzasadnieniem dlaczego ten sprint warto wykonać. Po ustaleniu celu sprintu Zespół Developerski buduje na swój użytek konkretny plan pracy nad wymaganiami wziętymi do sprintu. Wymagania te wraz z owym planem to Sprint Backlog.

 

Backlog sprintu

Obejmuje on listę zagadnień, którymi w czasie Sprintu zajmował się będzie Zespół aby osiągnąć Cel Sprintu uzgodniony z Właścicielem Produktu. Celowo określamy elementy Backlogu Sprintu zagadnieniami, zamiast pisać o zadaniach, bo też w Backlogu tym znajdować się mogą zarówno wymagania, nad którymi Zespół pracuje, błędy do rozwiązania, usprawnienia z ostatniej Retrospekcji czy zadania techniczne związane z narzędziami i praktykami wykorzystywanymi przez Zespół. Ponieważ to Zespół Developerski jest właścicielem Backlogu Sprintu, sam decyduje o jego zawartości i formie. Ta ostatnia często przybiera postać tablicy kanbanowej, służąc od razu jako radiator informacji na temat tego, co dzieje się w Sprincie.

Większość elementów wspomnianego Backlogu definiowana jest w czasie Planowania Sprintu, gdy Zespół w oparciu o prognozę tego, co zdoła zrobić, identyfikuje jak chce to zrobić. Czasami wymagania (na przykład w formie Historyjek Użytkownika) są tak małe, że ich dalsza dekompozycja na potrzeby pracy w Sprincie już nie ma sensu; zazwyczaj jednak taka dekompozycja następuje, choćby po to, by ułatwić pracę nad jednym wymaganiem kilku osobom i aby jawnie określić „rzeczy do zrobienia”.

 

Cel sprintu

Jedną z wartości Scrum jest skupienie (ang. focus). Dzięki skupieniu się na tym, co da się zrobić, ale też skupieniu na konkretnym celu, zespół jest w stanie organizować swoją pracę w iteracji, efektywnie radzi sobie z utrudnieniami i poszukuje najlepszych rozwiązań. Sprzyja temu określenie mocnego celu sprintu: zrozumiałego dla wszystkich, dającego się dobrze określić, realnie osiągalnego i przede wszystkim wartego osiągnięcia.

Cel sprintu ma wszakże jeszcze inne funkcje, mniej oczywiste. Przede wszystkim pozwala zespołowi dokonywać świadomych wyborów w każdej sytuacji, gdzie nie jest oczywiste, które rozwiązanie lub droga będzie najlepsza. Jest to trudne zwłaszcza jeśli porównujemy coś, co wydaje się mieć taką samą ilość zalet i wad. Jasny cel, do którego realizacji dąży zespół, pozwala wybrać takie rozwiązania, które sprzyjają osiągnięciu tego celu. Czasami wymaga to zrobienia szybkiego eksperymentu, aby potwierdzić, czy warto iść jedną, czy drugą drogą. Zamiast grzęznąć w analizach i dyskusjach, zespół świadomie spróbuje pójść dwiema drogami i po krótkim, ściśle określonym czasie, oceni jak daleko dotarł każdą z nich. To ułatwi wybór i stanowi dobry przykład korzystania z empiryzmu.

Inna funkcja celu sprintu ujawnia się, gdy złożoność i nieprzewidywalność technologii, wymagań lub otoczenia spowoduje, że prace w sprincie pójdą wolniej, niż zespół zakładał w czasie planowania iteracji. Można wtedy w kontekście celu sprintu zastanowić się z czego da się zrezygnować, lub jak ograniczyć zakres prac, aby cel nadal był osiągalny.

Cel sprintu przydaje się także, gdy ze względu na wyjątkowe okoliczności Product Owner musi negocjować z zespołem zmianę zakresu prac w sprincie. Zdarza się to na przykład w przypadku jakiejś awarii lub pilnej zmiany nie mogącej czekać na kolejny sprint – powodów ku temu może być wiele. O ile Scrum zakłada niezmienność wymagań w trakcie iteracji, nie wymusza to rezygnacji z pragmatyzmu – i tu pojawia się znów nasz cel sprintu. Mając go, możemy podjąć decyzję, z czego w iteracji zrezygnować, by wciąż osiągalny był ten cel, ale też by uzyskać czas niezbędny na poradzenie sobie z nieplanowanymi działaniami.