AgileAdept.pl
cel sprintu

Jak formułować Cel Sprintu?

Cel Sprintu (Sprint Goal) to obok Celu Produktu (Product Goal) i Definicji Ukończenia (Definition of Done) jedno z trzech Scrumowych zobowiązań (ang. commitment) Developerów. Powstaje w trakcie Planowania Sprintu i jest częścią Backlogu Sprintu. Temat z pozoru nie jest szczególnie odkrywczy i skomplikowany. Przecież, żeby zacząć jakąkolwiek pracę, musimy wiedzieć co chcemy dzięki niej osiągnąć, prawda?

Skoro jednak sformułowanie “Sprint Goal” pojawia się w Scrum Guide aż 19 razy to znak, żeby zastanowić się nad tym aspektem nieco dłużej. Zawsze gdy opowiadam o tym elemencie Scruma przypomina mi się pewien genialny w swojej prostocie cytat z “Alicji w krainie czarów” Charlesa Lutwidge’a Dodgsona piszącego pod pseudonimem Lewis Caroll.

cel sprintu analogia alicja

Moje doświadczenie pokazuje, że samo określenie celu często przysparza Zespołom Scrumowym wielu problemów. A zatem spiszę z pomocą.

Antywzorce związane z Celem Sprintu

Zanim odpowiemy sobie na pytanie jak stworzyć Cel Sprintu, żeby miało to sens i wspierało zespół, kilka porad jak tego nie robić. Sprawdź czy czasem w twoim zespole nie padają poniższe pomysły świadczące o niezrozumieniu tematu. Jeżeli jesteś Scrum Masterem, zareaguj zanim będzie za późno 😉

Gotowy Cel Sprintu przed Planowaniem

Pierwszy, bardzo często spotykany antywzorzec, to sytuacja, w której Product Owner przychodzi na Planowanie Sprintu z gotowcem Celu. Obwieszcza zgromadzonym, co powinno zostać zrealizowane w nadchodzącej iteracji i nie pozostawia pola do dyskusji. Spotkałem się w swojej karierze Scrum Mastera z pewnym Właścicielem Produktu, który wręcz wychodził z Planowania po ogłoszeniu Celu i rzuceniu: “clear? Go do”.

Oczywiście nie ma nic złego w tym, że PO ma jakąś swoją wizję i zalążek tego co chciałby mieć na koniec kolejnego Sprintu. Oczekuje się wręcz, że będzie przygotowany pod tym kątem. Nie mniej jednak Cel Sprintu powinien wynikać z dialogu i być wypracowany wspólnie przez cały Zespół w trakcie Planowania, a nie przed.

Cel Sprintu niezależny od Zespołu Scrumowego

Drugi antywzorzec to zobowiązanie się do Celu Sprintu, którego osiągnięcie nie zależy w pełni od Zespołu Scrumowego. Zdecydowana większość z nich posiada mniejsze lub większe zależności z innymi zespołami i często będzie coś od nich potrzebować. Nierzadko są to tematy blokujące dalszy postęp prac, przykładowo dostęp do środowisk testowych czy przebudowanie bazy danych.

W takich przypadkach często pada pomysł stworzenia życzeniowego Celu Sprintu w stylu: “Zbudowanie mechanizmu logowania i odblokowanie środowisk testowych”. Skoro wiemy z góry, że Cel nie zależy w pełni od Zespołu to z miejsca narażamy się na ryzyko jego nie dostarczenia. Dobrze było by mieć odblokowane środowiska testowe, ale czy jesteśmy pewni, że osoby za nie odpowiedzialne uporają się z problemem przez okres naszej iteracji?

Oczywiście należy robić wszystko, aby usunąć lub wyeliminować negatywny wpływ przeszkody jaka staje na drodze Zespołu. Nie mniej jednak dorzucenie jej do celu Sprintu z pewnością nie przyspieszy tego procesu.

Wymyślanie Celu Sprintu na koniec Planowania

Kolejny antywzorzec to prawdziwa plaga i przyczyna nie przespanych nocy Scrum Masterów ;). Wiele początkujących Zespołów Scrumowych traktuje niestety Cel Sprintu po macoszemu, a jego ustalenie zostawia na sam koniec jako najmniej istotny element planowania.

sprint goal

Planowanie Sprintu sprowadza się do wybrania luźno powiązanych ze sobą elementów Backlogu Produktu, tak aby ich łączną wartość mniej więcej odpowiadała średniej prędkości Zespołu. Do tego automatycznie przerzucane są wszystkie nieukończone elementy z poprzedniego Sprintu no i viola! Sprint zaplanowany. Wystarczy wpisać byle jaki Cel w odpowiednim polu w Jirze, kliknąć start i już mamy spokój na kolejne dwa tygodnie… 😉 Brzmi znajomo?

Jeżeli właśnie w taki sposób obywa się Planowanie Sprintu w twoim zespole, zaproponuj eksperyment i postarajcie się odwrócić tę kolejność.

Cel SMART

Jak w takim razie sformułować Cel Sprintu, aby uniknąć wspomnianych wyżej antywzorców? Czego może użyć Scrum Master, aby wesprzeć swój Zespół Scrumowy w tym temacie? Jak zwykle z pomocą przyjdzie nam kolejny anglojęzyczny i łatwy do zapamiętania akronim.

Budowanie celów SMART to technika o niesłabnącej popularności pomimo leciwego już wieku. Jej początki sięgają bowiem roku 1981, kiedy to po raz pierwszy George Doran opisał ją na łamach magazynu “Management Review”. Akronim SMART utworzony jest z następujących cech, jakie powinien posiadać cel:

S – specific (sprecyzowany, precyzyjny, konkretny) – innymi słowy Cel Sprintu nie może być zbyt ogólnikowy. Analogią mogą być tutaj popularne postanowienia noworoczne w stylu: będę lepiej się odżywiać i więcej ruszać. Co dokładnie znaczy lepsze odżywianie i więcej ruchu? Czy na przykład usuwamy całkowicie cukier z diety czy pijemy jedną puszkę słodkiego napoju tygodniowo mniej? Czy biegamy dystans pięciu kilometrów co drugi dzień czy po prostu idziemy na spacer dookoła domu raz na tydzień?

Wszyscy wiemy jak kończą się tego takie mało precyzyjne postanowienia noworoczne… Jeżeli nasz Cel Sprintu będzie podobnym, ogólnym sformułowaniem w stylu “poprawa wydajności aplikacji” to ciężko będzie w ogóle zweryfikować czy już został osiągnięty czy nie. Jeżeli tego typu cele pojawiają się w twoim zespole postaraj się podrążyć temat i spytaj co konkretnie chcemy osiągnąć w najbliższej iteracji.

Dobry Cel Sprintu odpowiada na pytanie dlaczego w ogóle warto go zaczynać? Czy podejmujemy wysiłek, żeby rozwiązać jakiś problem? Umożliwić coś nowego dzięki zaimplementowanej funkcjonalności Produktu? A może po prostu chcemy zrobić eksperyment w celu zweryfikowania pewnych założeń?

M – measurable (mierzalny) – czyli konkretny sposób zmierzenia to pochodna pierwszej cechy akronimu SMART. Jeżeli chcemy poprawić wspomnianą wyżej wydajność naszego produktu to powinniśmy wyrazić ją liczbowo. Przykładowo chcemy zmniejszyć prędkość ładowania się strony sprzedażowej o 30%.

cel sprintu cytat drucker

A – achievable (osiągalny) – w pierwszej, oryginalnej wersji akronimu literka “A” reprezentowała przymiotnik “assignable” czyli możliwy do przypisania do konkretnej osoby.
Obecnie jednak najczęściej funkcjonuje “achievable” lub “attainable” czyli osiągalny. Innymi słowy czy zrealizowanie celu jest w ogóle możliwe czy będzie graniczyło z cudem? Czy zespół posiada wszelkie niezbędne kompetencje, zasoby i wiedzę czy wiemy z góry, że choćby skały… krzyczały 😉 to raczej się nie uda?

R – relevant (istotny, wartościowy) – Cel Sprintu powinien reprezentować konkretną wartość, korzyść i przybliżać do osiągania Celów Produktu rozwijanego przez Zespół Scrumowy. Z kolei realizowane Cele Produktu powodują stopniowe materializowanie się wizji Produktu stworzonej przez Product Ownera.

T – time-bound (określony/ograniczony w czasie) – wróćmy jeszcze raz do analogii z postanowieniami noworocznymi. Nawet jeżeli nasz cel jest specyficzny, mierzalny, osiągalny i wartościowy to powinniśmy jeszcze określić do kiedy zobowiązujemy się na jego zrealizowanie. Przykładowo: chcę schudnąć 5 kilogramów. Czy jest to nasze wyzwanie na najbliższy tydzień czy na cały rok?
W przypadku Sprintów Scrumowych sprawa wydaje się dosyć prosta, bo same w sobie są ograniczone czasowo. A zatem nasz Cel Sprintu powinien być zrealizowany najpóźniej ostatniego dnia iteracji. Dla przypomnienia, Sprint może trwać maksymalnie miesiąc kalendarzowy.

Nie tylko SMART

Technika opisywania celów akronimem SMART jest chyba jedną z najpopularniejszych, ale nie jedyną. Jeżeli z jakiegoś powodu to narzędzie nie odpowiada twojemu zespołowi możesz skorzystać też z kilku alternatyw albo wypracować własne.

  • PURE (Positively stated, Understood, Relevant, Ethical)
  • ABC (Achievable, Belivable, Commited)
  • CLEAR (Collaborative, Limited, Emotional, Appreciable, Refinable)

Korzyści posiadania Cel Sprintu

Posiadanie jednego celu motywuje do podejmowania i doskonalenia pracy zespołowej oraz budowania współodpowiedzialności za osiągane rezultaty. Innymi słowy przestajemy szukać kozłów ofiarnych gdy pojawiają się problemy i nie zgrywamy bohaterów, gdy wszystko idzie gładko.

Wszystkim członkom zespołu powinno w równym stopniu zależeć na dostarczeniu użytecznego, wartościowego Przyrostu na koniec Sprintu. Powinni stale współpracować i wspierać się na dobre i na złe. Liczy się zrealizowany Cel oraz biznesowy efekt jaki za nim stoi.

Posiadanie Celu Sprintu przyczynia się także do poprawy skupienia na najistotniejszych rzeczach, a zatem jest praktycznym zastosowaniem jednej z wartości Scruma (focus). Stanowi punkt odniesienia, “latarnię morską”, która zawsze pomoże w obraniu właściwego kierunku i przypomnieniu o priorytetach, na przykład w trakcie Daily Scruma.

Cel Sprintu nie może się zmienić

Na koniec warto jeszcze dodać, że ustalony na Planowaniu Cel Sprintu nie może ulec zmianie, natomiast sposób jego realizacji i zakres Sprint Backlogu pozostaje elastyczny.

W trakcie prac, już po rozpoczęciu Sprintu, może okazać się, że Zespół nie przewidział pewnych aspektów swojej pracy. Przykładowo nie doszacował jej czy też wpadł na alternatywny sposób realizacji. Może wówczas negocjować zakres Backlogu Sprintu z Product Ownerem, ale Cel Sprintu pozostaje bez zmian.

Jedynym przypadkiem, gdy możliwa jest zmiana Celu to przerwanie Sprintu i natychmiastowe zaplanowanie nowego. Może to nastąpić w sytuacji gdy Cel Sprintu się zdezaktualizował i nie ma najmniejszego sensu jego kontynuowania. Przykładowo, w między czasie weszły w życie nowe uwarunkowania prawne, zmieniła się sytuacja na rynku czy uprzedziła nas konkurencja. Decyzję o przerwaniu Sprintu może podjąć wyłącznie Product Owner.

Jak wyglądał ostatni Sprint Goal twojego zespołu? Czy udało się uniknąć typowych antywzorców? Zachęcam do pozostawienia komentarza pod wpisem 🙂

Jarek Łojko

Dodaj komentarz

AgileAdept.pl