Planowanie Sprintu [agilestarter]

W naszym cyklu o podstawach agile przedstawiliśmy już sporo zagadnień, ale nie było jeszcze mowy o wydarzeniach scrumowych, które nadają rytm pracy zespołowi. Dzisiaj zatem pora na pierwsze w Sprincie, czyli Planowanie.


Skoro planowanie, to oczywiście odbywać się będzie na samym początku Sprintu. W wydarzeniu tym bierze udział cały Zespół Scrumowy. W Scrum Guide jest mowa o tym, że Planowanie ma dać odpowiedź na dwa pytania: CO chcemy zrobić w Sprincie oraz w JAKI sposób to COŚ chcemy zrobić. Spójrzmy zatem bliżej kolejno na obie części:

CO chcemy zrobić w Sprincie?

Zazwyczaj pojawiają się dwa scenariusze tej części: albo Product Owner przynosi cel, który chciałby zrealizować i wspólnie z zespołem decyduje, czy jest on zrozumiały, osiągalny i które zadania z backlogu służą temu celowi; albo Product Owner wskazuje, które zadania w backlogu są w tej chwili najbardziej wartościowe i wraz zespołem zastanawia się, jaki ich wykonaniu może przyświecać wspólny cel. Rzeczą tutaj najważniejszą, bez której nie możemy mówić o przejściu do dalszej części spotkania, jest Cel – to on będzie wskazywał drogę zespołowi, pomagał mu podejmować decyzje w trakcie Sprintu i motywował do wspólnej pracy. Czym jest cel i jak go dobrze sformułować, przybliżył szczegółowo Jacek w swoim artykule, więc ja pozwolę sobie tu zwrócić uwagę na kilka dodatkowych kwestii, które pojawiają się w trakcie pierwszej części Planowania.

Bardzo często początkujące zespoły borykają się z decyzją, czy wszystkie zadania trzeba „upchnąć” w celu, czy wolno brać na Sprint zadania, które nie będą częścią celu i czy w cel wchodzą błędy i tzw. utrzymaniówka. A zatem po kolei. Nie, nie musimy na siłę zawierać w celu wszystkie wybrane na Sprint zadania, i tak, możemy brać na Sprint zadania, które nie będą częścią celu. Rzadko kiedy mamy idealną (?) sytuację, że określiliśmy sobie cel i wybraliśmy zadania, które wypełnią nam całą pojemność sprintu. Zazwyczaj jest tak, że mamy jeszcze jakieś moce przerobowe i jesteśmy w stanie wziąć na sprint parę małych zadań, które mogą być poprawkami błędów, pracami utrzymaniowymi, czy dodatkową wartością dla klienta końcowego. Jeśli tylko zespół się zgodzi, że jest w stanie te zadania zrobić, a Product Owner widzi zasadność takiego wyboru, nic nie stoi na przeszkodzie, żeby zespół miał w Sprincie zadania poza celem. Należy jednak pamiętać, że cel realizujemy jako pierwszy, a zatem wszystkie dodatkowe zadania poczekają na swoją kolej i będziemy się mogli za nie wziąć dopiero wtedy, gdy upewnimy się, że cel już zrealizowaliśmy lub zrealizujemy niezagrożony. Co natomiast z utrzymaniówką i poprawą błędów ramach celu sprintu? Scrum Guide mówi, że cel ma służyć rozbudowie produktu (Przyrost), ale również, że celem może być wszystko, co służy wspólnej pracy zespołu. Stąd też uważam, że i naprawa błędów, i prace utrzymaniowe, jeśli odbywają się pod dobrym szyldem, jak najbardziej mogą być brane pod uwagę przy określaniu celu. Pamiętajmy jedynie, by zawsze dążyć do jak najbardziej jednoznacznego celu, przy którym na koniec Sprintu będziemy w stanie odpowiedzieć sobie na pytanie, czy go osiągnęliśmy, czy nie.

Niezależnie od tego, czy PO przyszedł z celem, czy wypracowano go po wskazaniu najwartościowszych zadań w backlogu, ostateczną decyzję o tym, ile zadań zostanie wziętych na Sprint, podejmuje zespół deweloperski. To te osoby mają najlepszą wiedzę na temat swoich możliwości, złożoności tematu, zależności między zadaniami i innymi zespołami. Oczywiście, warto, żeby PO od czasu do czasu podnosił poprzeczkę i testował wraz z zespołem, czy możliwe jest zwiększenie ilości zadań / Story Pointów na Sprint, ale powinno się to odbywać w merytorycznej dyskusji, gdzie obie strony znając metryki z dotychczasowej pracy i dokonań, mogą realnie podejść do zwiększania swoich możliwości.

W JAKI sposób to COŚ chcemy zrobić?

Skoro już mamy określony cel i wiemy, jakie zadania z Product Backlogu wybraliśmy na Sprint, trzeba zejść głębiej i rozpocząć właściwe planowanie prac. Tutaj pierwsze skrzypce gra zespół deweloperski, ponieważ będzie w tej części spotkania tworzył swój Sprint Backlog. Każda historyjka powinna zostać teraz rozebrana na elementy pierwsze, czyli mniejsze podzadania do wykonania. Te podzadania mogą już dotyczyć testowania, projektu, części frontendowej, programowania, prac infrastrukturalnych, słowem wszystkiego, co trzeba wykonać, żeby zadanie było można uznać za wykonane zgodnie z Definition of Done. Zespół może wspólnie pracować nad kolejnymi historyjkami, natomiast warto czasem podzielić deweloperów na mniejsze grupy, które wymieniają się opracowanymi historyjkami. W ten sposób uzyskujemy efekt podwójnego sprawdzenia kompletności podzadań. Rzadko kiedy bowiem zdarzają się sytuacje, by druga czy trzecia grupa nie dodała jeszcze jakichś podzadań do historyjki, bądź nie spytała pierwszej, dlaczego wskazała takie, a nie inne akcje do wykonania. Dzięki takiej współpracy zespół uczy się od siebie, wymienia wiedzą i jednocześnie bardzo dobrze doprecyzowuje zakres prac w każdej z historyjek.

Często mówi się, że na tym etapie Planowania nie jest potrzebny Product Owner. Faktycznie, jego rola tutaj jest znikoma, ale zachęcam, żeby jednak brał udział w tej części, choćby jako obserwator. Obok bowiem poszerzenia swojej wiedzy o kwestie techniczne, co nigdy nie jest do przecenienia, może się okazać, że będzie niezbędny zespołowi, jeśli ten w toku prac nad podzadaniami zacznie mieć wątpliwości co do realizowalności całości, zauważy niewidoczne wcześniej problemy czy zależności, albo wręcz wykryje coś sprzecznego z celem Sprintu. W takiej sytuacji PO na miejscu jest w stanie szybko skonsultować z zespołem problem, przeanalizować możliwe rozwiązania i w razie potrzeby przedefiniować cel lub zadecydować o wyrzuceniu z zakresu Sprintu którychś zadań.

Jeśli udało nam się podzielić historyjki na mniejsze podzadania, pozostaje nam zaplanowanie prac, o czym często zespoły zapominają i po Planowaniu tracą czas ponownie wracając do Sprint Backlogu.Tutaj zespoły mają do wyboru spektrum podejść – mogą zgrubnie rozplanować sobie cały Sprint, np. umieszczając na tablicy w formie kalendarza w kolejnych dniach historyjki i podzadania, mogą od razu zadeklarować, kto będzie do jakiego podzadania i historyjki przypisany, a mogą również szczegółowo rozpisać sobie tylko pierwszy dzień prac. A zatem teraz powinny paść pytania o to, co musimy zrobić w pierwszej kolejności, jak możemy ułożyć kolejność prac, kto czym się zajmie po Planowaniu, a nawet z czym chcemy skończyć pierwszy dzień Sprintu. Dopiero gdy odpowiemy sobie na te pytania, możemy uznać, że jesteśmy przygotowani do startu i możemy „odpalić” Sprint.

A na koniec jeszcze parę dodatkowych wskazówek przydatnych przy planowaniu, które łatwo umykają nam z pamięci:

  • Planowanie jest niezwykle łatwe, przyjemne i krótkotrwałe, jeśli w trakcie Sprintu poświęcicie odpowiednią ilość czasu na Refinement, czyli pielęgnację backlogu.
  • Refinement pomoże wam, jeśli dzięki niemu każde zadanie gotowe na Planowanie będzie spełniało Definition of Ready (co to takiego przeczytasz w Antywzorcach)
  • Łatwiej się planuje, jeśli zespół mierzy swoją prędkość 😉
  • Dobrze mieć gdzieś widoczny kalendarz na najbliższe tygodnie z zaznaczonymi nieobecnościami członków zespołu (urlopy, święta, L4)
  • Warto też zadać sobie w zespole na koniec Planowania dwa pytania: jak sprawdzimy, czy osiągnęliśmy cel oraz jak opowiemy przebieg naszego Sprintu postronnej osobie. Odpowiedzi na nie pozwolą nam upewnić się, że cały zespół tak samo rozumie cel i plan na jego wykonanie.

Komentarze do wpisu: “Planowanie Sprintu [agilestarter]

  1. Bardzo trafne podsumowanie tego wydarzenia w Scrum. Dobrze prezentuje zadania poszczególnych ról, ale jak według Was powinien angażować się SM w to wydarzenie… bo jego zadania artykuł trochę według mnie pominął….

    • Najkrócej zdefiniowałabym rolę SMa w Planowaniu pisząc, że trzyma rękę na pulsie, żeby to wszystko, o czym była mowa w artykule, miało szansę się wydarzyć. W przypadku mniej doświadczonych zespołów SM będzie prowadził zespół przez kolejne etapy spotkania, wskazywał na kolejne akcje do wykonania, proponował techniki, by ich wykonanie szło sprawniej i efekty były pełniejsze, oraz edukował zespół, by pamiętali o tym, po co w ogóle robią Planowanie. A jeśli zespół jest już doświadczony, ma opanowaną mechanikę Planowania i rozumie, w jakim celu się to spotkanie odbywa, SM może usunąć się w cień i obserwować, czy faktycznie zespół jest w stanie samodzielnie przeprowadzać Planowania. Wówczas daje tylko na bieżąco feedback, jeśli widzi niepokojące sygnały, i zadaje dodatkowe pytania, by wesprzeć zespół, jeśli zbacza z tematu. Pamiętajmy, że podstawowym zadaniem SMa jest wykształcenie zespołu, doprowadzenie go do pełnej samodzielności i zejście ze sceny 🙂

  2. Dziękuję za odpowiedz.
    Będąc przy temacie planowania – Czy planowanie wdrożenia całego projektu w perspektywie dłuższej niż jeden sprint powinno odbywać się podczas wydarzenia Planning czy raczej podczas innych wydarzeń Scrum?
    Dodatkowo kto w zespole jest odpowiedzialny aby taki plan (niezależnie czy to projekt fixed scope, fixed date czy scope and date not fixed)

    • Planowanie wdrożenia całego projektu to bardzo pojemne hasło. Najczęściej rozpatrywać możemy 2 przypadki:
      – Jeśli mówimy o wdrożeniu w sensie faktycznego „wrzucenia” czegoś na produkcję, to za podjęcie takiej decyzji odpowiada PO i to on planuje datę wdrożenia, biorąc pod uwagę ogólnie mówiąc „otoczenie biznesowe” i możliwości techniczne.
      – Jeśli mówimy o wdrożeniu w sensie zaplanowania, spriorytetyzowania i przekazania zespołowi propozycji prac, które nie zmieszczą się w jednym sprincie, wówczas mówimy o zarządzaniu Backlogiem Produktu. I znów – odpowiedzialny jest za to PO, a planowanie prac i priorytety będzie ustalał biorąc pod uwagę „otoczenie biznesowe”, estymaty zespołu i wartość biznesową. Po więcej informacji zapraszam do artykułu Dawida: http://www.agile247.pl/porzadkowanie-backlogu-jak-to-zrobic/.
      Ucięło ci część drugiego pytania – jeśli nie chodziło o PO, o którym pisałam wyżej, napisz pytanie jeszcze raz, proszę.

  3. Ucięło 🙂
    Pytałem która rola jest odpowiedzialana za przygotowanie takiego planu, ale zostało to już nakreślone w odpowiedzi tj. PO współpracując z zespolem.
    Podsumowując (pytanie czy dobrze?) to PO jest odpowiedzialny za oczekiwany przez interesariuszy termin realizacji projektu, za harmonogram, postęp prac.
    Zespół natomiast ma mieć perspektywę planowania jednego sprintu zgodnie z bieżącym backlog podczas Planningu (dodatkowo oczywiście refinement pod katem kolejnych sprintów).

    • Trochę doprecyzuję twoje podsumowanie, żeby nie zostało błędnie zrozumiane 😉
      1. Tak, PO jest odpowiedzialny za termin realizacji projektu, harmonogram i postęp prac, ale:
      – jeśli mamy termin (nieprzekraczalny), to pamiętajmy, że pracując zwinnie mamy możliwość wyboru prac, które zostaną wykonane. Nie musimy na dany termin zrobić wszystkiego, a tylko to, co daje najwyższą wartość. Zadaniem PO jest merytoryczne uzasadnienie i obronienie swoich decyzji odnośnie realizowanego zakresu.
      – jeśli potrzebny jest harmonogram, pamiętajmy, że ze sprintu na sprint może on ulegać zmianom, nie jest wyryty w kamieniu. Wszystko zależy od tego, jak poszły prace w poprzednim sprincie, jak zmieniają się potrzeby interesariuszy i/lub klientów, ile osób jest w stanie pracować (urlopy, L4 itp.), czy pojawiły się nowe okoliczności i nowe zadania na backlogu. Najważniejsze, żeby PO dostarczał zainteresowanym aktualną informację na temat prac.
      – jeśli postęp prac = zadania wykonane i niewykonane, to zespół jest współodpowiedzialny, bo na nim spoczywa sprawczość w sprincie. Współodpowiedzialny oczywiście w dobrym tego słowa znaczeniu, czyli pomaga PO podjąć decyzje na temat zakresu prac w sprincie, dba o szybkie wykrywanie potencjalnych problemów i utrudnień w pracach i angażuje się na 100% w realizację prac.

      2. Zespół może mieć perspektywę jednego sprintu, ale po pewnym czasie całkiem naturalnie zacznie dopytywać PO, jaki jest obraz całości, po co robimy te małe, sprintowe cele, czemu to służy. Rozmowa z zespołem o tzw. „big picture” pozwala lepiej zaangażować go i uruchamia w zespole większe pokłady kreatywności. Dodatkowo dobrze, żeby zespół znał dłuższą perspektywę prac, bo jego członkowie są w stanie wychwycić zależności między z pozoru rozdzielnymi zadaniami, zasugerować inne, czasem lepsze ułożenie prac ze względu na technologię rozwiązania, czy inne niuanse domenowe. Ich wsparcie merytoryczne jest dla PO bezcenne, więc zachęcałabym jednak, by dzielić się z zespołem czymś więcej niż tylko planem na kolejny sprint.

  4. Super! Kilka lat temu moja firma wprowadziła scruma i zakochałem się w nim od pierwszego wejrzenia 😉 Do tego stopnia, że wykorzystuje pewne „zmodyfikowane” zasady Scruma do zarządzania osobistymi zadaniami i celami. Wasz blog jest bardzo przydatny w pogłębianiu wiedzy. Dziękuję.:)

  5. […] Cyklicznie oraz poprawnie realizowany Przegląd Sprintu zapewnia, że cykl inspekcji oraz adaptacji produktu jest regularnie realizowany. Zespół w określonych, stałych odcinkach czasu otrzymuje informację zwrotną na temat wytworzonego Przyrostu produktu i może użyć tej wiedzy w toku dalszych prac nad rozwojem produktu. Powoduje to, że ryzyko budowania niewłaściwego produktu zmniejsza się, ponieważ produkt w cykliczny sposób jest prezentowany interesariuszom. W przypadku zauważenia przez nich uchybień, odchyleń od oczekiwań lub błędów, mogą szybko reagować, natomiast ewentualne zmiany mogą być uwzględnione przez zespół już podczas kolejnego Planowania Sprintu. […]


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