Jednym z najczęściej pomijanych aspektów Scruma jest Cel Sprintu (ang. Sprint Goal). Nie da się ukryć, że jest to jedno z wielu odstępstw od Scruma, które prowadzą do znienawidzonego ScrumBut. Ale czasami mogą też pomóc skupić się na tym, co najważniejsze.
Cel Sprintu został zaktualizowany wraz z opublikowaniem nowej wersji Scrum Guide w listopadzie 2020. Szczegóły znajdziesz we wpisie Cel Sprintu 2020.
Cel Sprintu
Według definicji ze Scrum Guide, Cel Sprintu to „zamierzenie, które zostanie osiągnięte w ramach Sprintu poprzez implementację wybranych elementów Backlogu Produktu. Cel Sprintu pomaga Zespołowi Deweloperskiemu zrozumieć, w jakim celu będzie on tworzyć Przyrost”. Nie jest to szczególnie jasna definicja i nic dziwnego, że wiele osób nie czuje idei stojącej za Sprint Goal.
Często Cel Sprintu w ogóle jest pomijany lub ustalany dopiero pod koniec danej iteracji. Niektórzy zaczynają o nim myśleć dopiero na Sprint Retrospective. Ale są też większe przewinienia…
Najgorszy możliwy Cel Sprintu to „wszystkie wymagania ze Sprint Backlogu„.
Jedyne, w czym Zespołowi Deweloperskiemu pomoże wskazanie wszystkich wymagań jako Celu Sprintu to uświadomienie sobie, że pracują w fabryce, a nie w zwinnej organizacji. Nigdy nie powinno być tak, że wszystko jest najważniejsze, chociażby dlatego, że plan tworzony w trakcie planowania to jedynie prognoza, a nie zobowiązanie.
Cel Sprintu to „powód, dla którego robimy ten sprint”. Jeśli chcemy zaktualizować naszą ofertę w odpowiedzi na działania konkurencji, a przy okazji dokonać kilkunastu drobnych usprawnień w systemie, to nietrudno jest wskazać główny priorytet. Wiemy, po co pracujemy. Wszystko, co zrobimy ekstra będzie miłym dodatkiem, ale nie powinno być realizowane kosztem Celu Sprintu.
Sprint Goal to kolejne narzędzie, które zapewnia zrozumienie na linii IT-biznes. Dzięki niemu obie strony mają poczucie tego, co się dzieje, a zespoły deweloperskie nie tylko wiedzą, co robią, ale też mają świadomość, po co.
Dobry Sprint Goal
Każdy dobry Cel Sprintu będzie namacalny. Jest to coś, z czego odbiorca będzie mógł korzystać, na czym będzie mógł zarabiać lub po prostu będzie to usprawnienie, które wywoła uśmiech na jego twarzy. W tym celu trzeba spełnić przynajmniej dwa warunki: funkcjonalność musi działać i musi ona zostać wdrożona.
Zastanawiając się nad Celem Sprintu warto zadać sobie dwa pytania: „na czym nam najbardziej zależy?” i „bez czego będziemy mieli kłopoty?”. Bardzo często okazuje się, że naprawdę krytyczny jest mały podzbiór ściśle powiązanych ze sobą funkcjonalności.
Wyobrażając sobie zarówno korzyści płynące z sukcesu jak i negatywne konsekwencje porażki sprawiamy, że nasza praca staje się bardziej namacalna zarówno dla interesariuszy, jak i Zespołu Scrumowego. Mówiąc bardzo nieprecyzyjnie – wszyscy powinni lepiej „czuć” po co robimy bieżący sprint.
Dobry Cel Sprintu jasno pokazuje, co jest naszym priorytetem. Jeżeli zbliża się okres świąteczny i wiemy, że musimy przygotować nasze aplikacje i infrastrukturę od strony wydajnościowej, to przykładowym Celem Sprintu może być „utrzymanie wydajności na poziomie x w trakcie świąt”. Wydrukujmy to, przyklejmy hashtag #sprintgoal i powieśmy na ścianach w całym biurze. Wtedy na pewno każda osoba będzie wiedziała nad czym teraz pracujemy.
Dobry Sprint Goal to jedno zdanie.
Jak większość scrumowych idei, także i ta sprawdza się najlepiej w przypadku małej skali projektu. Zwykle przecież mówiąc „Scrum” myślimy o jednym-dwóch zespołach i częstych wdrożeniach. A co, jeśli zajmujemy się czymś bardziej skomplikowanym?
Gdy brakuje Celu Sprintu…
Trudno mówić o czymś takim jak Sprint Goal, jeśli najbliższe wydanie zaplanowane jest za pół roku. Tu od razu ciśnie się na usta pytanie „czy jeśli wydajemy się dwa razy w roku to jeszcze jest to Scrum?”, na które odpowiadam: tak. Istnieje wiele różnych sytuacji, w których wydawać częściej się nie da. To problem, z którym trzeba się jak najszybciej uporać, ale zanim to nastąpi musimy zadbać między innymi o komunikację strategii i wizji.
Trudno w takiej sytuacji przekonywać członków Zespołu Deweloperskiego, że istotne jest ukończenie jakiejś funkcjonalności w sprincie numer 37, jeżeli wdrożenie nastąpi dopiero w okolicy sprintu 50-tego i nikt wcześniej nie będzie z tego fragmentu systemu korzystał. Skąd więc ten pośpiech?
Cel Sprintu nie musi być ściśle powiązany z tym, co otrzyma użytkownik końcowy. Może on równie dobrze dotyczyć kamienia milowego, proof of concept czy po prostu fragmentu rozwiązania potrzebnego do podjęcia określonych decyzji. Nawet budowa wersji demonstracyjnej, która będzie pokazana potencjalnemu klientowi to dobry cel.
Inaczej mówiąc, Celem Sprintu jest stworzenie Minimum Viable Product.
O ile nasza praca nie jest powiązana z innymi i nie mamy ustalonych kamieni milowych, to być może to, co się dzieje w każdym poszczególnym sprincie jest dla nas mniej istotne, a bardziej liczy się efekt końcowy – prawdziwie wdrażalny przyrost. „Prawdziwie” znaczy tu nie tylko działającą aplikację, ale i okno serwisowe, w którym te wdrożenie może nastąpić.
Sprint Goal vs. Release Goal
Z pomocą przychodzi tutaj Cel Wydania (ang. Release Goal). Jest to dokładnie to samo, co opisany powyżej Cel Sprintu (Sprint Goal), ale dotyczy najbliższego wydania. Zamiast skupiać się na tworzeniu kawałków oprogramowania, skupiamy się na całej układance i momencie, kiedy faktycznie będziemy „wdrażalni”.
Cel Wydania przypomina zainteresowanym o tym, co jest najważniejsze i sprawia, że wszyscy grają do jednej bramki. Nie jest też sztuczny, bo wszyscy „czują” co to znaczy wydanie, jak często występuje i co powinniśmy wtedy dostarczyć użytkownikom. Więcej na ten temat możecie przeczytać w tekście o Release Planning.
W przypadku rzadkich wdrożeń Cel Sprintu, o ile nie jest powiązany z zależnościami pomiędzy zespołami, bywa sztuczny. Bo przecież de facto przesuwając realizację wymagań pomiędzy sprintami nie opóźniamy momentu wdrożenia. Czy przygotujemy tę funkcjonalność dziś, czy za miesiąc i tak będzie ona wdrożona dokładnie za pół roku.
Bezcelowy Cel Sprintu
Zdarzają się organizacje, gdzie nie pracujemy w trybie projektowym, ale utrzymaniowym. Jeśli naszym głównym zadaniem jest poprawa błędów, obsługa użytkowników i okazyjnie dostarczenie usprawnienia czy nowej funkcjonalności, to trudno mówić tu o celach czy nawet o wydaniach.
Scrum nie jest uniwersalną metodyką. Nie sprawdzi się w każdej sytuacji. Jeżeli uważasz, że w danym przypadku absolutnie nie da się wyznaczyć ani Celu Sprintu, ani Celu Wydania, to zastanów się czy aby na pewno Scrum to dobry wybór.
W pracy czysto utrzymaniowej często o wiele lepiej sprawdzają się takie rozwiązania jak Kanban czy XP albo wręcz mob programming. Nie stosujmy do wszystkiego jednej techniki tylko dlatego, że ją dobrze znamy. W końcu „gdy w ręku trzymasz młotek, wszystko zaczyna wyglądać jak gwoździe”.
Jeśli Scrum jest właściwą metodyką dla twojego projektu, to na pewno uda ci się znaleźć Cel Sprintu. W ostateczności – przynajmniej Cel Wydania. W chwili zwątpienia wróć do dwóch prostych kwestii: co wywoła uśmiechy, a czego brak sprowadzi gromy z jasnego nieba?
Więcej o zwinnym zarządzaniu wymaganiami i wyznaczaniu planu, celów i wizji opowiadamy na szkoleniu Wymagania w projektach agile. Sprawdź, czy nie jest to coś, z czego Twoja organizacja może skorzystać.
