Planowanie Sprintu

Każdy Sprint rozpoczyna się od spotkania zwanego Planowaniem Sprintu (ang. Sprint Planning), podczas którego Zespół Scrum sporządza prognozę tego, jakie wymagania zaimplementuje w ciągu Sprintu i jaką korzyść przyniesie to interesariuszom (np. użytkownikom produktu).

Jest to spotkanie, w którym bierze udział cały Zespół Scrum (a więc Product Owner, Scrum Master i Developerzy). Jego celem jest zastanowienie się co można zrobić w nadchodzącym Sprincie, jak to zrobić, a przede wszystkim po co realizowany będzie ten Sprint. Produktem Planowania jest Backlog Sprintu (ang. Sprint Backlog) oraz Cel Sprintu (ang. 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 około 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 (Przyrostem), oraz które wymagania powinny być zrealizowane, żeby osiągnąć ten cel. Zespół Scrum wspólnie dyskutuje i ustala zakres pracy. Developerzy kolejno, od góry, analizują wymagania z Backlogu Produktu, a następnie prognozują 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 Developerzy budują 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 Product Ownerem. 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 Developerzy pracują, błędy do rozwiązania, usprawnienia z ostatniej Retrospekcji czy zadania techniczne związane z narzędziami i praktykami wykorzystywanymi przez Developerów.

Ponieważ to Developerzy są właścicielami Backlogu Sprintu, samo 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. Zwracamy przy tym uwagę na to, że samo użycie takiej tablicy nie świadczy o użyciu metody Kanban w połączeniu ze Scrumem.

Większość elementów wspomnianego Backlogu Sprintu definiowana jest w czasie Planowania Sprintu, gdy Developerzy w oparciu o prognozę tego, co zdołają zrobić, identyfikują jak chcą to zrobić. Czasami wymagania – na przykład w formie Historyjek Użytkownika (ang. User Stories) – 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”.

Backlog Sprintu jest artefaktem ciągle zmiennym, ponieważ odzwierciedla aktualny plan osiągnięcia Celu Sprintu i opisuje pracę Developerów do końca iteracji. W czasie Planowania Sprintu powstaje jego pierwsza wersja, po czym w kolejnych dniach pracy developerskiej Backlog jest modyfikowany tak, by odzwierciedlić to, co wydarzyło się już w Sprincie. Wiele Zespołów Scrum, które pracują sekwencyjnie nad elementami Backlogu Produktu podjętymi do realizacji w Sprincie (zamiast realizować wiele z nich równolegle), na Planowaniu Sprintu tworzy dość precyzyjny plan realizacji tylko dla pierwszych kilku wymagań, a dla pozostałych zgrubną koncepcję realizacji. Taki Backlog Sprintu ulega powolnemu doprecyzowaniu w kolejnych dniach.

W Scrumie Backlog Sprintu jest artefaktem, który ma pomóc zapewnić przejrzystość postępu prac w Sprincie i wyjaśniać jaki plan mają Developerzy na osiągnięcie Celu Sprintu oraz realizację usprawnień zidentyfikowanych w czasie Retrospekcji Sprintu poprzedniego. O kształcie i zawartości Backlogu Sprintu decydują Developerzy i odpowiadają wspólnie za jego przejrzystość.

Cel Sprintu

Z Backlogiem Sprintu związane jest w Scrumie zobowiązanie (ang. commitment) jakim jest Cel Sprintu (ang. Sprint Goal). Jest to odpowiedź na pytanie jaką wartość przyniesie interesariuszom (np. użytkownikom) ten Sprint. Cel ten stanowi wyjaśnienie, po co realizowany jest Sprint i jest nierozerwalnie związany z Backlogiem Sprintu, który wyjaśnia w jaki sposób Developerzy zamierzają Cel ten osiągnąć.

Cel Sprintu ma w Scrumie określone cechy:

• W każdym Sprincie jest tylko jeden Cel Sprintu – Zespół Scrum nie może jednocześnie dążyć do osiągnięcia wielu różnych Celów w ramach jednej iteracji.
• Cel Sprintu jest niezmienny – zakres prac niezbędnych do jego osiągnięcia może zmieniać się dynamicznie, ale sam Cel pozostaje stały; Product Owner może zdecydować o przerwaniu Sprintu, jeśli osiągnięcie Celu Sprintu przestało mieć znaczenie, tym niemniej z możliwości tej korzystać należy wyłącznie w sytuacjach wyjątkowych.
• Cel Sprintu powinien wynikać z bieżącego Celu Produktu i być krokiem w stronę jego osiągnięcia.
• Cały Zespół Scrum uzgadnia Cel Sprintu, ponieważ stanowi on zobowiązanie wszystkich osób w Zespole.

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 jeszcze inne funkcje, mniej oczywiste. Przede wszystkim pozwala Developerom 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ół Scrum, 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, Developerzy świadomie spróbują pójść dwiema drogami i po krótkim, ściśle określonym czasie, ocenią jak daleko dotarli 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. 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 Developerami 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 dużą stabilność (stałość) 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.