Jak stworzyć dobry cel sprintu?

Definiowanie celu sprintu dla wielu zespołów z czasem staje się przykrym obowiązkiem – robimy to byle jak, by był (bo Scrum Guide wymaga), albo nie robimy tego wcale. Nie musi tak być! Dobrze sformułowane cele sprintu mogą stać się świetnym narzędziem pomagającym w skupieniu na tym co ważne i samoorganizacji zespołu.

„Cel sprintu” nie przez przypadek pojawia się w Scrum Guide aż 19 razy – jest on istotnym i nieodłącznym elementem Scruma. Jest celem pośrednim w dążeniu do osiągnięcia Celu Produktu. Dobrze sformułowany Cel Sprintu będzie jednoczył i motywował Zespół, nakierowując go na dostarczanie wartości. Zamysł wydaje się prosty, jednak w praktyce popełniane jest wiele błędów, które powodują, że Zespoły tracą szansę na wykorzystanie całego wachlarza dobrodziejstw, które daje Cel Sprintu.

Czym jest cel sprintu?

Cel Sprintu jest zobowiązaniem Developerów wobec Sprint Backlogu (SB) do dostarczenia wartościowego rezultatu. Cel ten dodaje przejrzystości do SB. Odpowiada na pytanie „po co” wykonujemy daną pracę. Dzięki niemu Zespół, organizacja oraz Interesariusze wiedzą jaka jest spodziewana wartość dostarczona przez ukończony w danym Sprincie Przyrost.

Każdy Sprint jest małym krokiem w kierunku osiągnięcia Celu Produktu. Na Cel Sprintu możemy zatem patrzeć jak na cel pośredni, który będzie wskazywał najbardziej wartościowy rezultat na danym etapie rozwoju Produktu, przybliżający Zespół do osiągnięcia większego celu w przyszłości.

Cel Sprintu jest obowiązkowym elementem Scruma. Występuje w kontekście każdego wydarzenia – tworzony jest na Planowaniu; codziennie wykorzystywany do inspekcji pracy podczas Daily, prezentowany podczas Sprint Review, by ukazać drogę w kierunku osiągnięcia Celu Produktu.

Cel jest także często punktem wyjścia do rozmów podczas Retrospektywy, a nieaktualny Cel Sprintu jest jedynym powodem, dla którego Product Owner może podjąć decyzje o anulowaniu Sprintu. Cel Sprintu ma ogromne znaczenie dla całego procesu, a zatem również dla sukcesu dostarczania wartości przez Zespoły Scrumowe.

Co daje nam dobrze sformułowany Cel Sprintu?

Dobry Cel Sprintu będzie nadawał sens wykonywanej pracy, motywując Zespół do działania. Będzie jednoczył we wspólnej pracy ukierunkowanej na uzyskanie wartości oraz osiągnięcie oczekiwanych rezultatów.

Cel Sprintu powinien być codziennie wykorzystywany przez Deweloperów. Pomaga im utrzymać skupienie na tym co ważne. Podczas każdego Daily Scruma Deweloperzy dokonują inspekcji, czy wykonywana praca przybliża ich do osiągnięcia Celu Sprintu. Przyświeca ich działaniom i ułatwia podejmowanie decyzji podczas ustalania planu na najbliższy dzień.

Dobrze sformułowany Cel Sprintu wskazuje oczekiwaną wartość, ale nie narzuca na Zespół sposobu jej dostarczenia. Odpowiada na pytanie „dlaczego”, a nie „jak”. Będzie umożliwiał elastyczne podejście do jego realizacji, wspierając samoorganizację Zespołu. Jeżeli w trakcie pracy nad Przyrostem Zespół odkryje nowe fakty mające wpływ na ustalony plan, to Cel Sprintu będzie pomagał Deweloperom adaptować tenplan oraz da możliwość negocjacji zakresu Sprintu z Product Ownerem.

Kto i kiedy tworzy Cel Sprintu?

Cel Sprintu tworzony jest podczas Planowania. Pozostaje jeden i niezmienny przez cały okres trwania Sprintu.

Z propozycją wartości danego Sprintu przychodzi na Planowanie Product Owner. Opowiada o tym jaki jest oczekiwany rezultat planowanego Przyrostu. Ostateczny kształt Celu Sprintu, będący zobowiązaniem Dewelopera, jest wspólnie ustalany w kooperacji wszystkich członków Zespołu. Takie podejście zapewnia nie tylko wspólne rozumienie celu, ale również pomaga Deweloperom w prawdziwym zobowiązaniu się do jego dostarczenia.

Ustalony Cel Sprintu powinien zostać uwidoczniony w Sprint Backlogu.

Jak tworzyć cel sprintu?

Przejdźmy zatem do sedna – jak tworzyć Cele Sprintów, by jednoczyły, motywowały i nadawały sens pracy Developerów?

Dobre cele Sprintu będą zrozumiałe i przejrzyste dla każdego w Zespole. Będą dawały przestrzeń na elastyczne podejście do jego realizacji, poprzez wskazywanie kierunku prac, a nie sposobu jej wykonania. Skupiać się będą na outcomie, nie na outpucie.

Poniżej opisałam parę metod określania celów (nie tylko Sprintu). I choć nie wszystkie idealnie nadają się do tworzenia Celu Sprintu, to mogą być pomocne w stawianiu pierwszych kroków w pracy nad tworzeniem znaczących celów.

1️⃣ Sposób Romana Pichlera

W sposobie zaproponowanym przez Romana Pichlera, sformułowanie Celu Sprintu polega na odpowiedzi na 3 pytania:

• Cel – Jaki jest cel wykonywanej pracy? Co chcemy osiągnąć (outcome)?
• Metoda – Jak osiągniemy oczekiwany rezultat?
• Metryka – Skąd będziemy wiedzieć czy osiągnęliśmy oczekiwany rezultat?

Według Autora cel może dotyczyć jednego z trzech zagadnień: test hipotezy o użytkowniku w celu lepszego zrozumienia jego zachowania, ograniczenie ryzyka (np. technicznego) lub dostarczenie funkcjonalności. Na początku pracy nad daną funkcjonalnością często zaczyna się od hipotez i ryzyk, by przejść do celów skupionych na dostarczaniu funkcjonalności, gdy mamy lepszą wiedzę o użytkowniku i możliwościach technicznych. Przykładowymi celami mogą być: architektura rozwiązania wspiera wymaganą wydajność; wiemy, czy użytkownik skorzysta z funkcjonalności X; funkcjonalność Y gotowa do wdrożenia.

Następnie dobiera się metody osiągnięcia oczekiwanego rezultatu. Będą się one różnić, w zależności od typu celu. Nie zawsze ukończenie demo, zaprezentowanie na Review i zbieranie feedbacku od Interesariuszy jest jedyną możliwością w Scrumie. Dla testowania hipotez i ryzyk mogą to być: budowa prototypów, testy użyteczności lub testy A/B. Warto też w tym miejscu określić grupę docelową, która będzie zaangażowana w ocenę naszego „jak”.

Na koniec dobieramy miary, które potwierdzą osiągnięcie określonego celu. Jest to uzupełnienie Celu Sprintu, który omawiamy podczas Sprint Review. Jeżeli mówimy o rezultacie, to często możemy go osiągnąć dopiero po wdrożeniu dla użytkowników. Metrykami dla celów mogą być przykładowo: 2/3 Interesariuszy ocenia pozytywnie pokazany na Review Przyrost, 80% użytkowników skorzystało z funkcjonalności przynajmniej raz w ciągu pięciu dni od wdrożeniu na środowisko Produkcyjnego, uzyskujemy o 20 punktów procentowych lepszy wynik dla jednej z propozycji w testach A/B.

📕 Zobacz formatkę do umieszczania swoich odpowiedzi.

2️⃣ SMART czy FAST?

Najbardziej popularną metodą ustalania celów jest model SMART, który definiuje cel jako:

Innym podejściem, u którego podstaw kryje się krytyka podejścia SMART, jest FAST:

Zaprezentowane modele delikatnie się różnią, kładąc nacisk na inne właściwości celów. Cele SMART są mierzalne, co jest istotne w empirycznym procesie jakim jest Scrum. Sprint świetnie nadaje się jako sposób określenia celu w czasie. Podejście FAST natomiast podkreśla przejrzystość celu dla wszystkich zaangażowanych w proces oraz znaczenie częstej inspekcji – co daje zbieżność z filarami Scruma.

Oba podejścia podkreślają sprecyzowanie oraz ambitność / istotność celów. Wykazano, że określanie takich celów pomaga w skupieniu i wytrwałości w ich osiąganiu. Dzieje się tak jednak, gdy mamy wpływ na kształt celu oraz osobiście się do niego zobowiązujemy (cel nie jest narzucany przez inne osoby).

Dla złożonych problemów, z którymi mamy do czynienia w Scrumie, ważne jest by Zespół czuł, że zna strategię na osiągnięcie celu. W przeciwnym wypadku, takie ambitne cele mogą działać demotywująco. Cele skupione na zdobyciu wiedzy (learning goals, np. o zachowaniach użytkownika), mogą być dobrymi celami na początku pracy nad funkcjonalnością, by ułatwić określenie danej strategii. Kolejne cele będą już mogły być określone wokół wydajności rozwiązania (performance goals).

3️⃣ FOCUS dla Scrumowych Celów Sprintu

Ostatni, i chyba najlepiej dopasowany do realiów Scruma, jest model FOCUS zaprojektowany przez Maarten Dalmijn:

Fun – zabawny, Outcome-oriented – zorientowany na rezultat, Collaborative – wypracowany w wyniku współpracy, Ultimate – ostateczny, Singular – pojedynczy

Według modelu FOCUS dobry Cel Sprintu jest inspirujący, motywujący i łatwy do zapamiętania (fun). Mówi o tym jaki jest oczekiwany rezultat (outcome-oriented) i wskazuje ostateczne wytłumaczenie, dlaczego dany rezultat ma wartość dla użytkownika i biznesu (ultimate). Wypracowany wspólnie przez wszystkich członków Zespołu pojedynczy cel wspiera współpracę i skupienie na tym co ważne (singular, collaborative).

ANTYWZORCE: często spotykane problemy

Cel Sprintu w zamyśle jest prosty – tworzymy jedno zdanie, które wskaże hipotezę wartości dostarczonej w danym Sprincie. Dlaczego jednak tak dużo Zespołów ma z tym problem? Spójrzmy na często spotykane problemy:

1️⃣ Zespół nie określa Celu Sprintu

Brak Celu Sprintu nie blokuje dostarczania Przyrostów i wartości Produktu. Gdy go jednak nie używamy, to tracimy ważne dla procesu możliwości – np. codzienną inspekcję pracy w odniesieniu do celu. Gdy nie ma wyodrębnionego Celu Sprintu, to wykonanie wszystkich elementów Sprint Backlogu i wykonanie planu staje się celem samym w sobie. A jak wiadomo, plany w złożonym środowisku często stają się nieaktualne. Zespół, zamiast na rezultacie, skupia się jedynie na wygenerowaniu outputu. Nie daje to przestrzeni na adaptacje, ograniczając samoorganizację Deweloperów.

2️⃣ Zespół robi różne rzeczy i nie wiadomo jaki obrać Cel

Często zdarza się, że Zespoły robią kilka kawałków Product Backlogu, które nie są ze sobą powiązane. Mimo, że nie jest to idealna sytuacja, bo powoduje konieczność zmiany kontekstu pracy, to jednak w praktyce często trudno jest jej uniknąć. Niemożliwym wydaje się wtedy zbudowanie jednego celu, który będzie określać wartość dostarczoną przez Przyrost.

Cel Sprintu powinien dotyczyć tego co ma najwyższy priorytet. Wyobrażamy sobie sytuację, w której wszystko się pali i odpowiadamy na pytanie – co jest krytyczne do dostarczenia pod kątem biznesowym? Jeżeli zidentyfikujemy taki element, to wokół niego definiujemy Cel Sprintu. Dzięki takiemu określeniu Celu Sprintu, Zespół będzie umiał podjąć właściwą decyzję o kolejnym ruchu, gdy napotka trudną sytuację.

I na koniec – pamiętajmy, że nie każdy realizowany PBI musi być uwzględniony w Celu Sprintu. Poprawne jest podejście, w którym Cel Sprintu wskazuje najważniejszy rezultat, a Zespół w planie Sprintu uwzględnia również elementy niezwiązane z obranym celem – np. naprawa błędu z produkcji, czy usprawnienie techniczne.

3️⃣ Cel jako kolektyw PBI do zrobienia

Kolejny anty-wzór to cele sformułowane jako lista elementów Product Backlogu (PBI) do zrealizowania. Przykładowo: „Ukończyć PBI o numerach 134, 155 i 156”. Tak określone cele nie wspierają skupienia i nie dają elastyczności, ale przede wszystkim nie wskazują znaczenia wykonywanej pracy. Takie cele, zamiast wspierać, zabijają kreatywność Zespołu. Dobitnie pokazują brak zrozumienia dla tworzenia i wykorzystywania Celu Sprintu w codziennej pracy w Scrumie.

Jeżeli Zespół notorycznie nie wykonuje pracy, która mogłaby zostać ujęta w formie jednego celu nastawionego na rezultat, to być może Zespół taki nie powinien pracować w Scrumie. Być może inna zwinna metoda byłaby bardziej przystosowana do realiów wykonywanej pracy (np. Kanban).

Podsumowanie

Cel Sprintu jest ważną częścią Scruma. Dobrze sformułowany będzie określał oczekiwany rezultat na koniec Sprintu, jednocząc i motywując Zespół do dostarczania wartości oraz umożliwiając im elastyczność. I choć określenie dobrego Celu bywa trudne, ważne by rozumieć jak wartościowe może być to narzędzie.

Można eksperymentować z różnymi formami celów. Dobrym pomysłem jest testowanie jak działają różne podejścia dla danego Zespołu, a następnie dawanie sobie przestrzeni na inspekcję i adaptację. Pierwszy znaczący Cel Sprintu najpewniej nie będzie idealny. Warto jednak co Sprint podejmować wysiłek definiowania dobrego celu dla uzyskania wszystkich opisanych korzyści.

📕 Materiały dodatkowe

Poniżej zabrałam dla Ciebie kilka dodatkowych materiałów, na których bazowałam pisząc artkuł i które pozwolą Ci jeszcze bardziej zgłębić temat celów sprintów:

• Five Questions for a Sprint Goal!
• Nine Sprint Goal Principles to Get Your Scrum Team Going;
• Scrum from the trenches – the Sprint Goal
• Getting to Done: Creating Good Sprint Goals
• The 11 Advantages of Using a Sprint Goal
• The Sprint Goal Lifecycle