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 Backlogu Sprintu. 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.
Posłuchaj odcinek #013 podcastu Porządny Agile Porządne planowanie Sprintu