Co to jest Cel Sprintu?

Pracując z zespołami scrumowymi wielokrotnie spotykam się z sytuacją, w której zespół nie korzysta z możliwości, jakie daje dobrze skonstruowany Cel Sprintu. W tym artykule wyjaśnię czym jest Cel Sprintu, jakie są korzyści z jego stosowania oraz podpowiem jak taki cel stworzyć w praktyce.

Co to jest Cel Sprintu?

Cel Sprintu jest założeniem, które Zespół Deweloperski planuje osiągnąć jako efekt pracy w Sprincie. Jest on ustalany przez zespół podczas Planowania Sprintu i stanowi dla Zespołu Deweloperskiego wsparcie w podejmowaniu decyzji w trakcie trwania prac w Sprincie. Cel Sprintu może dotykać różnych aspektów: dostarczenia konkretnej funkcjonalności dla użytkowników, testowania hipotez produktowych cz też badania ryzyk związanych z produktem.

Jakie są korzyści posiadania Celu Sprintu?

Umiejętne korzystanie z Celu Sprintu niesie za sobą kilka istotnych korzyści dla Zespołu Deweloperskiego. Poniżej wymieniłem kilka najważniejszych:

  • Pomaga zrozumieć, jaką wartość wnosi dany Przyrost produktu – dobrze określony Cel Sprintu daje Zespołowi Deweloperskiemu jasną informację, dlaczego realizujemy konkretny Sprint. Przykładowo, Cel Sprintu brzmiący “Udostępnić użytkownikom płatność on-line” daje jasną informację zespołowi, jakie cele biznesowe stoją za tą konkretną iteracją rozwoju produktu.
  • Wspiera pracę zespołową – określenie jasnego celu powoduje, że cały Zespół Deweloperski skupia się na jego realizacji, a tym samym przedkłada osiągnięcie Celu Sprintu przez zespół ponad indywidualne aspiracje i zadania realizowane przez poszczególnych członków zespołu.
  • Daje swobodę sposobu realizacji Sprintu – zwykle istnieje więcej niż jeden sposób osiągnięcia Celu Sprintu. Daje to Zespołowi Deweloperskiemu pewną swobodę działań, uzależnioną od aktualnego składu zespołu, wiedzy dotyczącej produktu, umiejętności czy też dostępnej technologii. W takich sytuacjach bliska współpraca z Właścicielem Produktu pomaga podjąć trafne decyzje.
  • Jest wskazówką co do priorytetów w Sprincie – w sytuacji w której pojawia się wątpliwość w Sprincie co do tego, czym powinien się zająć Zespół Deweloperski, Cel Sprintu podpowiada im następny ruch. Przykładowo, mogłaby pojawić się pokusa w zespole rozwiązania świeżo zgłoszonego, ale niezbyt istotnego błędu. Aktualny stopień zaawansowania realizacji Celu Sprintu pomaga podjąć decyzję, czy faktycznie powinniśmy zająć się rozwiązaniem wspomnianego błędu, czy jednak skupić się na pracy nad realizacją celu iteracji.
  • Potwierdza ustalenia Zespołu Deweloperskiego z Właścicielem Produktu – Cel Sprintu jest formułowany przez Zespół Scrumowy i pomaga w budowaniu wspólnego zrozumienia tego, co ma być efektem pracy w Sprincie. W praktyce, Właściciele Produktu najczęściej sami proponują Cel Sprintu podczas Planowania Sprintu lub wypracowują go wspólnie z Zespołem Deweloperskim.
  • Wspomaga komunikację z interesariuszami – dobrze określony Cel Sprintu jest jasnym i zwięzłym komunikatem dla osób zainteresowanych rozwojem produktu na temat aktualnie prowadzonych prac. Przykładowo, Cel Sprintu brzmiący “Umożliwienie użytkownikom zalogowania się poprzez Facebook” daje czytelną informację dla interesariuszy na temat tego, czym w danym Sprincie zajmuje się Zespół Deweloperski. Na bazie takiej informacji mogą podjąć decyzję, czy dołączyć do Przeglądu Sprintu i przygotować się z wyprzedzeniem do dyskusji podczas tego wydarzenia.

Jak stworzyć dobry Cel Sprintu?

Jest kilka rzeczy o których warto pamiętać podczas tworzenia Celu Sprintu:

  • Użyj czasowników – czasowniki pomagają określić, co konkretnie ma się zadziać jako efekt realizacji Celu Sprintu. Przykładowo, cel “Nowy panel admiński dla użytkowników” nie mówi nam, co zamierzamy z tym panelem zrobić. Wdrożyć? Przetestować? Przebudować? Precyzyjnie dobrany czasownik rozwiewa wątpliwości i wprost komunikuje nasze intencje.
  • Twórz konkretne cele – Cel Sprintu powinien jasno określać o jakiej skali zmian mówimy. Przykładowy cel “Zmniejszyć współczynnik odrzutu na stronie” nie mówi nam nic o tym, jakiego efektu się spodziewamy. Zmniejszyć współczynnik o połowę? Zmniejszyć o 10%? Czy jak zmniejszymy o 1% to będzie wystarczająco? Co więcej, cel powinien być łatwy do binarnego stwierdzenia, czy został zrealizowany, czy nie.
  • Unikaj formułowania tzw. “wielocelu” – zdarza się, że pojawia się pokusa stworzenia celu, który polega na realizacji zadania A, B oraz C. Takie sformułowanie Celu Sprintu powoduje, że traci on swoje właściwości. Przykładowo, zmniejsza możliwości zespołu w obszarze wyboru sposobu jego realizacji. Innym minusem jest potencjalna pokusa rzadszego komunikowania się wewnątrz zespołu, który po rozdzieleniu pomiędzy siebie zadań (A, B i C) uzna, że “przecież każdy wie co ma zrobić”.

Podsumowanie

Dobrze przygotowany Cel Sprintu pomaga Zespołowi Deweloperskiemu zrozumieć kontekst biznesowy wykonywanej pracy, daje pewną swobodę działania oraz wspiera współpracę w zespole. Pomimo, iż trzeba poświęcić chwilę na jego stworzenie, jest on wartościowym drogowskazem zarówno dla Zespołu Deweloperskiego jak również dla interesariuszy, śledzących rozwój produktu.

A jak Wy radzicie sobie z Celem Sprintu? Podzielcie się w komentarzach!

Źródło zdjęcia: https://www.flickr.com/photos/jurgenappelo/12908090375/

Komentarze do wpisu: “Co to jest Cel Sprintu?

  1. Dodałbym od siebie, że Cel Sprintu jest dobrym mechanizmem niejako zmuszającym do przeorganizowania Product Backlogu (z task-oriented na goal-oriented).
    Albo odwracając powyższe: aby można było tworzyć dobre biznesowe Cele Sprintu, najpierw trzeba odpowiednio ułożyć Product Backlog.
    Jaki z tego morał:
    Jeśli ułożenie Celu Sprintu sprawia ci kłopot, przyjrzyj się konstrukcji swojego Product Backlogu 🙂

    • Jacek Wieczorek

      Dzięki Krzysztof, dzięki za ujęcie tego w ten sposób. Jak słyszę, że nie ma Celu Sprintu, to zapala mi się lampka na zasadzie czy aby na pewno ktoś tutaj faktycznie zarządza produktem, skoro właśnie zostanie wydane kilkanaście/kilkadziesiąt tysięcy na Sprint a nie jest wyraźnie powiedziane „dlaczego”.

  2. Dobry, i potrzebny temat – dzięki Jacek!
    Mając już na ‚liczniku’ kilka lat doświadczeń ze Scrumem i wiele, wiele sprintów za sobą, muszę przyznać, że wyznaczanie celu sprintu to nadal jedno z tych największych wyzwań. Do tego co w artykule dorzucę kilka słów od siebie:
    * ustalanie celu sprintu to challenge, w który (jako PO) zawsze próbuję zaangażować zespół, nawet jeśli na dzień dobry piłeczka jest odbita (jak pisze wyżej Jacek, cel jest ustalany przez zespół; nie jest więc narzucany przez PO)
    * w pewnym momencie zacząłem stosować AC do celu, i u mnie w większości przypadków się sprawdza
    * naprawdę ciężko jest objąć wszystkie PBI jednym celem – czasami niestety trzeba pójść na drobne ustępstwa lub zastosować krytykowany w artykule ‚wielocel’ (zgadzam się, że trzeba go unikać, jednak są sytuacje, gdy byciem bardziej scrumowym od jego twórców sparaliżuje planowanie)

    Ważne kwestie, które można by dodać do drugiego/ kolejnego artykułu w tym temacie:
    * kiedy powinno się ustalać cel sprintu, przed czy po planowaniu? i jak to wpływa na sam proces planowania…
    * ustalanie celu sprintu a długość iteracji – ma to jakikolwiek wpływ?
    * jak zweryfikować, czy cel został dowieziony?
    * cel sprintu w iteracji bez tzw. fajerwerków (aka, mało sexy sprint)
    * czy można czasami z celu sprintu zrezygnować? No ten jeden, jedyny raz… 🙂

    Powyższe napisałem na dużym spontanie – jestem stałym czytelnikiem, ten temat jednak jakoś najbardziej zmobilizował mnie do wypowiedzi 🙂
    Pozdr!

    • Cel Sprintu i wybrane PBI są przedstawiane przez Product Ownera. Pomysł na ten Sprint to zdecydowanie odpowiedzialność PO. Zespół Develoeprski może challengować (ładne polskie słówko) czy osiągnięcie tego będzie realne. Może trzeba przyciąć, przenegocjować. Ostateczny Cel Sprintu ustala cały Scrum Team.

      Można powiedzieć, że Acceptancce Criteria celu to po prostu zrealizowanie PBI pod niego podpiętych, ponieważ PBI wynikają z celu.

      Tak, zdarza się, że nie wszystkie PBI pasują do Celu Sprintu. Ale nadal Cel Sprintu jest jeden. PBI nie pasujące do Sprintu są wypełniaczami i Zespół Developerski zacznie nad nimi pracować dopiero jak osiągnie Cel Sprintu. Wiele Celów to brak Celu i trochę sztuka dla sztuki. Można porównać to do wysłania komandosów na kilka misji jednocześnie. Raczej będą mieli problem się zorganizować.

      Żeby ustalić Cel Sprint PO może zadać sobie takie pytania:
      – po co robię ten Sprint?
      – jaka jest wartość biznesowa tego Sprintu?
      – na co chce wydać pieniądze?
      – co się zmieni po tym Sprincie?

      * ustalanie celu sprintu a długość iteracji – ma to jakikolwiek wpływ?
      Nie. Jeśli Cel jest za duży na jeden Sprint, to można go podzielić na mniejsze. Podobnie jak wielkość PBI vs długość Sprintu. Czasem posiadanie roadmapy, celu wydania pomaga lepiej kształtować Cele Sprintu.

      * jak zweryfikować, czy cel został dowieziony?
      PBI do niego podpięte są Done

      * cel sprintu w iteracji bez tzw. fajerwerków (aka, mało sexy sprint)
      What ever makes PO happy. Jeśli ma wartość, jeśli jest wart wydania kosztu zespołu, to tak.

      * czy można czasami z celu sprintu zrezygnować? No ten jeden, jedyny raz
      A czy można czasem zrezygnować z retrospektywy? No ten jeden, jedyny raz 😉
      A jeśli trudno jest określić sensowny Cel Sprintu, to może lepiej nie wydawać pieniędzy i go nie robić? Jaka będzie z niego wartość.

    • Jacek Wieczorek

      Dzięki Marek za rozległy i wartościowy komentarz. Ekstra, że zdecydowałeś się go napisać 🙂

      Ciekawy pomysł z AC do celu. Skojarzyło mi się „kluczowymi miarami” z OKR.

      Zgadzam się, nie zawsze można objąć wszystkie PBI celem, wystarczy jeden błąd w produkcie z przeszłości do rozwiązania, który nie wpisuje się w cel. Żeby były takie przypadki, że jeden PBI jest spoza celu, to byłoby dobrze! Częściej spotykam sytuacje, w której występuje tzw. bigos, czyli każdy PBI jest z innej bajki i wtedy zwykle powstaje jakiś sztuczny cel, jak np. wspomniany w komentarzu przez Krystiana „25 SP”.

      Odnośnie punktów na potencjalnie kolejny artykuł, moje spojrzenie jest takie:

      1) doświadczałem sytuacji, w których Cel Sprintu był jasny od początku Planowania (przynosił go PO do dyskusji z ZD) jak i sytuacji w których na skutek efektów poprzedniego Sprintu oraz samego procesu planowania na podstawie aktualnych priorytetów z PB, wykształcał się na koniec Planowania.

      2) osobiście jestem fanem krótkich (1 tyg.) Sprintów stąd cele automatycznie muszą brać to pod uwagę, są więc zwykle mniejsze/bardziej precyzyjne

      3) zakładając, że PB jak i SB zawiera całą pracę dot. produktu, to spodziewałbym się spełnienia DoD tych elementów + demonstracji faktycznego produktu

      4) myślę, że szczególnie dla „mało sexy sprintów” Cel Sprintu może być elementem, który sprawi, że stanie się „bardziej sexy”

      5) wolałbym dyskusję „a dlaczego mielibyśmy” 🙂

      Jestem ciekawy Twojego punktu widzenia na te punkty.

    • @ „naprawdę ciężko jest objąć wszystkie PBI jednym celem – czasami niestety trzeba pójść na drobne ustępstwa lub zastosować krytykowany w artykule ‚wielocel’ (zgadzam się, że trzeba go unikać, jednak są sytuacje, gdy byciem bardziej scrumowym od jego twórców sparaliżuje planowanie)”

      Moim zdaniem cel nie musi, a nawet nie powinien obejmować 100% zakresu Sprintu. W takiej sytuacji brak ukończenia choćby jednego z wielu elementów powodowałby, że zespół nie osiągnął celu. To z kolei nie wpływałoby pozytywnie na morale takiego zespołu. Poza tym – jeśli wszystko jest ważne (skoro jest w celu), to oznacza, że nic tak naprawdę nie jest ważne (to dlatego o backlogu mówimy, że jest uporządkowany, a nie spriorytetyzowany).
      Kojarzę, że któryś z „guru scrumowych” wspominał by cel obejmował maksymalnie do 50-60% zakresu. To pewnie taka wartość na wyczucie, ale dla mnie ma sens, by nie przedobrzyć i nie wystawiać na nadmierne ryzyko tego celu, jeszcze przed samym rozpoczęciem prac deweloperskich.

      Jeszcze sposób na zobrazowanie tego przyszedł mi do głowy, na wzór anegdoty od Stevena Coveya (m.in. 7 nawyków skutecznego działania):
      gdybyśmy wzięli małe akwarium – to jest nasz Sprint,
      włożyli do niego kamienie, tak, że więcej już się nie zmieści – to nasz cel sprintu,
      i gdyby się mogło wydawać, że to już cały zakres sprintu, w końcu żaden kamień więcej się nie mieści,
      to możemy jeszcze zasypać to piaskiem, który wejdzie między szczeliny – to te zadania w sprincie, które nie wspierają bezpośrednio celu, ale również są w zakresie sprintu.
      A na koniec jeszcze to wszystko możemy zalać wodą 🙂

      Gdybyśmy zaczęli od wody i od piasku – wtedy kamieni już nie zmieścimy. To powinno dać odpowiedź na to czy cel sprintu wyznaczać przed czy po właściwym planowaniu sprintu.

  3. Mam wrażenie, że cześć wypowiadających się osób nie czuje skąd się biorą cele. Prowadziłem wiele projektów, większość dość skomlikowanych technicznie, bo w C++ z 1.5 mln linii kodu i nie pamiętam, żebym kiedykolwiek miał problem z określaniem celów. Ale to co istotne, to najpierw określałem cele, a potem były zadania. Sprawę znacznie ułatwiało, że do niedawana byłem zwyczajnym team leaderem z dużą autonomią bez Scruma, a zwłaszcza sformalizowanego zarządzania zadaniami i takimi utopiami jak INVEST. Mając dobrych ludzi łatwiej było mi powiedzieć, dokąd mają dojść (czasami nawet na przestrzeni miesiąca) dając im szeroką autonomię, ewentualnie wzyznaczając po drodze kierunki pośrednie niż dokładnie rozpisywać plan na krótkie zadania. Bardzo dobrze to ujął Krzysztof: zmiana podejścia z „task-oriented” na „goal-oriented”, ale to się tylko łatwo mówi, bo w praktyce oznacza większą autonomię zespołu i większą swobodę dla niego w określaniu a nawet zmianie zadań i nierzadko w trakcie sprintu, a to wymaga zaufania, dość dojrzałego zespołu, który przede wszystkim myśli o produkcie. Od pewnego czasu jestem Product Ownerem i nawet mnie zadziwia, z jaką łatwością to doświadczenie wpisuje się w Scruma.

    Dla mnie idealną analogią do zrozumienia czym są cele i skąd się biorą jest pionierskie wejście na szczyt góry. Na początku jasny jest cel ostateczny, być może nawet łatwo go opisać, niekiedy go wszyscy widzą, a czasmi jest zasłonięty lub w chmurach, niemniej w każdym wypadku nie wiadomo, jak do niego dotrzeć. Wtedy bada się górę, a właściwie to, co widać, i określa parę celi pośrednich, które w informatyce mają nazwę kamieni milowych. To co je charakteryzuje, to dość zrozumiałe, nierzadko oczywiste kryteria ich wyznaczenia i czasami nazywają się celami strategicznymi. Cele te są drogowskazami do wyznaczenia ścieżek ale znowu również one mogą nie być proste i wtedy rekurencyjnie wyznaczamy w nich cele drugiego rzędu. To co istotne, to aby dobrze określić cele, nie można dobierać ich do gotowych zadań ani do czasu sprint, bo zadań po prostu jeszcze nie ma. W ten sposób wyłaniają nam się naturalne cele a kryteria ich wybrania oraz uzasadnienia są cenną informacją dla zespołu, więc warto to zmaterializować w product backlogu np za pomocą EPIC-ów. Dopiero teraz jest czas na formułowanie zadań i estymowanie, co się może udać zrealizować w najbliższym czasie i jak. Jeśli wiadome jest, że do następnego naturalnego celu jest za daleko w następnym sprint’cie, to prawie zawsze daje się on ekstrapolować, można też go sformułować w taki sposób: najbliższy cel główny to Rysy, w tym sprincie postarajcie się dojść do Buli, ale jeśli to okaże się niemożliwe, to zadowolę się, jeśli osiągnięcie co najmniej Czarny Staw. Także jest dla mnie chorą sytuacją dobieranie celu do gotowych zadań, bo w moim świecie to cele prowadzą, a nie zadania. Jasno sformułowane cele wyznaczają zespołowi kierunek wchodzenia na szczyt i dają możliwość bez konsultacji z Product Ownerem zmiany zakresu zadań, a nawet ich anulowanie lub dodawanie nowych (oczywiście w pewnych sensownych granicach), kiedy natrafią na niespodziewane przeszkody np.: wielką szczelinę, która nie była widoczna. Product Owner ma z tego korzyść dużą korzyć, bo nie jest nadmiernie wciągany w bieżące problemy w sprint’cie, co zazwyczaj jest koszmarne w projektach mocno innowacyjnych.

    Wyznaczanie kamieni milowych i celów pośrednich jest trudne ale tylko dla osób niedoświadczonych albo beztalęci. To jest tak, jak z jeżdżeniem samochodem i programowaniem – trzeba jeździć i programować, żeby umieć. Nie można wyuczyć się tego z książek – po prostu trzeba mieć odpowiedni przebieg. Nie ma uniwersalnych recept na wyznaczanie celi – tak jak każda góra jest inna, tak każda rzeczywistość projektowa niepowtarzalna. Ale można wymienić istotne czynniki uniwersalne, które powinny być brane pod uwagę przy wyznaczaniu celi. Ja do najważniejszych zaliczam: jak najszybsze zdobycie wiedzy projektowej przez zespół, jak najszybsze ruszenie z kodem do przodu i nawet jeśli potem wszystko trzeba przepisać, rzadko kiedy pierwsze podejście do nieznanej rzeczy jest udane, dbanie o motywację poprzez rozwój intelektualny i technologiczne członków zespołu, dbanie o satysfakcję interesariuszy, aby nie stracili nadzieii, identyfikacja łatwych efektów WOW, identyfikacja i omijanie niebezpiecznych ryzyk, jak najszbsze zrozumienie przez klienta, czego dokładnie chce, uwzględnienie chorej polityki w firmie. Można oczywiście jeszcze dużo wody polać ale właśnie takimi kwestiami kieruje się Product Owner wyznaczając ścieżkę rozwoju projektu, co z kolei istotnie wpływa na zadania i priorytety. I tutaj występuje pewien istotny problem: podejście zadaniowe do teamu pozwala Product Owner-owi na ukrycie pewnych czynników np. politycznych a czasami braku wizji rozwoju projektu natomiast podejście poprzez cele wymaga odkrycia raczej wszystkich kart, co może być nieakceptowalne.

    Projekty są rozmaite jak i płaszczyzny ich klasyfikacji, ale na pewno w jednej z płaszczyzn mamy takie oto dwa bieguny: projekt technologicznie zaawnsowany i innowacyjny ale z prostą i niezmienną w czasie specyfikacją oraz projekt technologicznie prosty ale z z rozbudowaną i zmienną w czasie specyfikacją funkcjonalną. W pierwszym wypadku projekt wymaga Product Ownera technicznego, który rozumie istotę takich zagadnień jak osiągnięcie zadowalającej wydajności, zrobienie dobrego projektu klas, potrzebę refaktoryzacji, podejście eksperymentalne, bezsensowność szacowania czasu pewnych zadań. Taki Product Owner nie będzie miał trudności z uwzględnieniem tej problematki i wyobrażeniem sobie jej wpływu na postęp lub regres projektu i dzięki temu prawidłowo wyznaczy cele pośrednie, które okażą się rzeczywistym torem rozwoju projektu. Natomiast biznesowy Product Owner raczej sobie nie poradzi stwierdzając, że on nie rozumie co jeszcze ma zrobić po naiwnie prostoliniowym przełożeniu prostych wymagań funkcjonalnych na zadania. W drugiej sytuacji, kiedy projekt jest technologcznie prosty a wymagania funkcjonalne złożone i zmienne, to cele i ścieżka rozwoju projektu nie jest uwarunkowana aspektami technologicznymi lecz wiedzie w taki sposób, aby klient/odbiorca jak najszybciej zrozumiał i mógł określić, co dokładnie chce i mógł też jak najmniejszym kosztem zmieniać to, czego był najmniej pewien. W tej sytuacji zdecydowanie lepszym będzie biznesowy Product Owner, który żyje w świecie klienta i łatwo wyczuwa naturę jego potrzeb, której klient nie potrafi sobie w pełni uświadomić ale który reaguje uśmiechem i okrzykiem „właśnie tego potrzebowałem” widząc kolejno ukończane etapy.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x