Po co jest Sprint Planning?

W poście tym przyglądam się korzyściom jakie daje nam Planowanie Sprintu. Jest to zebrana porcja wiedzy oraz moich przemyśleń na temat tego zdarzenia Scrumowego. Czy kiedykolwiek zastanawiałeś się, dlaczego członkowie zespołów scrumowych podczas miesięcznego Sprintu „marnują” 8 godzin? Co prawda, w przypadku krótszych Sprintów „marnują” ich mniej, ale jednak. Z tego postu dowiesz się po co to „marnotrawstwo”. Jeżeli masz trudność, żeby przekonać kogoś, że planowanie ma sens, ten post da Tobie kilka argumentów w dyskusji. Dowiesz się, również czego się spodziewać i czego oczekiwać od zespołu po dobrze wykonanym planowaniu…

Przebieg planowania

Sprint Planning jest zdarzeniem Scrumowym, które rozpoczyna Sprint. Zgodnie z tym, co jest zapisane w Scrum Guide nie powinien trwać dłużej niż 8 godzin w przypadku miesięcznego Sprintu. W przypadku krótszych Sprintów jest to zazwyczaj mniej. W trakcie spotkania, uczestnicy tego zdarzenia scrumowego, powinni stworzyć plan na najbliższy Sprint. Aby to zrobić, muszą odpowiedzieć na dwa pytania: co zamierzają wytworzyć na koniec sprintu oraz jak zamierzają tego dokonać?

Produkt planowania

Oznacza to, że muszą wybrać zakres funkcjonalności, które zostaną dostarczone i zintegrowane z Inkrementem na koniec Sprintu. Ponadto muszą uzgodnić jak zamierzają tego dokonać. W efekcie powstaje produkt tego zdarzenia scrumowego czyli prognoza na osiągnięcie Celu Sprintu.

Rozpoczynając planowanie Sprintu zespół powinien wziąć pod uwagę nie tylko co jest do wykonania, ale również poziom jakości w jakiej wymagany zakres powinien zostać dostarczony, czyli Definition of Done. Definicja ukończenia produktu jest źródłem istotnych informacji o tym, jakie konkretne czynności członkowie zespołu powinni wykonać. Jest to pomocne przy szacowaniu możliwości zespołu, gdyż wiemy jakie zadania wynikające z DoD powinny trafić do Sprint Backlogu.

Przed rozpoczęciem

Do Sprint Backlogu trafiają, przede wszystkim funkcjonalności wzbogacające wartość produktu dla użytkownika. Choć nie tylko. Sprint Backlog powinien zawierać „całą pracę” jaką zespół będzie zajmował się w czasie Sprintu. Jeżeli nie jest to pierwszy Sprint nowego produktu to istnieje już Product Backlog. Przed przystąpieniem do planowania wraz z całym zespołem Product Backlog powinien być uprzednio przygotowany. W zależności od etapu rozwoju zespołu oraz decyzji Product Ownera może on zadbać o to sam lub też zaangażować zespół. Jakkolwiek do tego dojdzie Product Backlog powinien być uporządkowany, transparentny oraz powinien wyrażać wizję i strategię produktu. Te trzy cechy sprawiają, że Zespół Deweloperski może dużo łatwiej zdecydować jakie elementy wybrać do Sprint Backlogu. Dobrze przygotowany Backlog Produktu, w sposób widoczny, wpływa na efektywność przebiegu planowania.

W trakcie

Przystępując do planowania, członkowie zespołu powinni wziąć pod uwagę swoje velocity oraz capacity, zakres funkcjonalności reprezentowany przez elementy Product Backlog oraz poziom jakości wyrażony przez Definicję Ukończenia (DoD). Zgodnie z nowym wydaniem Scrum Guide 2017 zespół powinien również zaplanować wdrożenie usprawnień, które zdecydował się podjąć podczas ostatniej Retrospekcji Sprintu. Jeżeli zespół uzna to za stosowne, może zaprosić dodatkowe osoby, które pomogą mu przygotować lepszy plan. Może to być na przykład przedstawiciel klienta albo członek innego zespołu.

Planowanie Sprintu obraca się wokół odpowiedzi na dwa wspomniane wcześniej pytania: co oraz jak? We wcześniejszych wersjach Scrum Guide planowanie było bardzo wyraźnie podzielone na dwie fazy wynikające z tych dwóch pytań. Obecnie nie ma takiego podziału i cały Zespół Scrumowy (łącznie z Product Ownerem) powinien być obecny. Brak formalnej agendy oznacza, że sposób przeprowadzenia spotkania zależy od osób uczestniczących. Jest tylko jeden warunek. Powinien pojawić się plan.

Najczęściej jednak zespoły decydują się w pierwszej kolejności wybrać cały zakres, a następnie przystępują do układania planu. Obie te czynności mają bardzo istotną rolę. Praca całego zespołu powoduje wymianę wiedzy wszystkich osób, które później będą pracowały nad wytworzeniem Inkrementu. Jest to duża różnica w porównaniu z podejściem kaskadowym. Zamiast przekazywać dokumentację projektową między silosami kompetencyjnymi, w czasie Sprint Planningu możliwie jak najwcześniej angażujemy wszystkie potrzebne osoby. Niewątpliwą zaletą takiego sposobu postępowania jest chociażby, redukcja błędów wynikających ze złego zrozumienia zakresu.

Sprint Backlog

Kolejną istotną różnicą w stosunku do podejścia kaskadowego jest fakt, iż to Zespół Deweloperski ustala jaki Sprint Backlog jest możliwy do wykonania w Sprincie. Wynika to z kilku przesłanek. Po pierwsze, samoorganizacja. Ciężko mówić o samoorganizacji jeżeli zespół nie jest w stanie sam wybrać zakresu i wziąć odpowiedzialności za rezultat. Jeżeli zakres do wykonania zostanie narzucony, to na kim spoczywa odpowiedzialność? Po drugie, Zespół Deweloperski jako grupa ekspertów jest najbardziej kompetentny, aby określić co jest możliwe do osiągnięcia. Ciężko wymagać od nich jakości, jeżeli ich głos nie będzie brany pod uwagę. Po trzecie, współdecydowanie wpływa na morale i podnosi podmiotowość pracowników. Po czwarte, wpływa na rozwój. Można powiedzieć, że zespół sam reguluje ilość stresu jaka będzie dla niego rozwojowa. Dobrą ilustracją jest tutaj siłownia na której sami dobieramy ciężar, dzięki któremu rozwijamy nasze mięśnie.

Prognoza

Prognoza czyli plan na dostarczenie Celu Sprintu. We wcześniejszych wersjach Scrum Guide zamiast słowa prognoza (ang. forecast) używano słowa zobowiązanie (ang. commitment). Zaobserwowano, że presja takiego zobowiązania jest niekorzystna i powoduje straty w jakości dostarczanych rozwiązań. Straty te w konsekwencji są bardzo kosztowne. Zmiana ta podkreśla stochastyczny charakter procesu wytwórczego. Zobowiązanie jednak nie znika, gdyż jest jedną z wartości scrumowych i dotyczy postaw członków zespołu.

Cel Sprintu

Zespół Scrumowy odpowiadając na pytanie co jest możliwe do zrealizowania w Sprincie powinien stworzyć Cel Sprintu. Powinien on odzwierciedlać to co deweloperzy chcą osiągnąć swoją pracą na koniec Sprintu. To właśnie Cel Sprintu sprawia, że są zespołem, a nie grupą osób. Jest to również mocne narzędzie w rękach Product Ownera, gdyż współtworzy go razem z zespołem. Przy jego pomocy nadaje on kierunek i skupia wysiłek deweloperów na celach biznesowych jakie chce osiągnąć.

Jest to również umowa pomiędzy IT, a przysłowiowym biznesem, że to co jest do osiągnięcia pozostaje niezmienne przez jeden Sprint. To ograniczenie sprawia, że Product Owner musi posiadać wizję rozwoju produktu oraz przemyśleć kolejne kroki swoich działań, co w wielu przypadkach nie jest oczywiste. Stworzenie dobrego Celu Sprintu nie jest trywialne. Wymaga uprzedniego przygotowania, pracy z Backlogiem Produktu oraz przewidywania konsekwencji swoich działań. Problem ze stworzeniem Celu Sprintu jak w soczewce pokazuje Impedimenty, które powinny zostać rozwiązane, aby zwiększyć produktywność zespołu.

Po planowaniu Sprintu

W efekcie omawianego zdarzenia scrumowego każdy z członków Zespołu Scrumowego powinien znać Cel Sprintu, wiedzieć co i jak zamierza wykonać w nadchodzącym Sprincie. Powinien powstać również Sprint Backlog odzwierciedlający plan (prognozę) przygotowany przez zespół.

Sprint Backlog jest artefaktem, który może i powinien być modyfikowany w czasie Sprintu. Zespół jest zobowiązany do dostosowywania planu do pojawiających się szans i zagrożeń. Każdy, kto ma choć trochę doświadczenia ze złożonością wie, że czym innym jest planowanie a czym innym jest podążanie za planem.

Co innego

Na koniec chciałbym porównać Sprint Planning do planowania w podejściu kaskadowym oraz w Kanbanie.

Mechanika Scruma sprawia, że jesteśmy zachęcani, aby plan rozwoju produktu pojawiał się w miarę postępu prac, przyrostowo. Ktoś może powiedzieć, skąd w takim razie wiem jak produkt finalnie otrzymam. Tego tak naprawdę nie wiadomo. Planując i wytwarzając produkt iteracyjnie, dajesz sobie szansę na znalezienie dobrej i szybkiej odpowiedzi na aktualne potrzeby rynku. Daje to niebagatelną przewagę w porównaniu z długotrwałą analizą projektową, która w momencie jak trafia do programistów jest nie na czasie. Zazwyczaj sprawia ona też dużo problemów ze zrozumieniem co autor miał na myśli. Kto inny planuje, a kto inny wykonuje zadania. Planując scrumowo unikamy przekazywania pracy między silosami kompetencyjnymi, a wiedza na temat tego co i jak ma zostać wytworzone pojawia się od razu we właściwym miejscu.

No tak, ale podejście iteracyjne lub przyrostowe może być realizowane również w Kanbanie. To prawda. Podstawową różnicą jest opcjonalność jaką daje Kanban. W Kanbanie możesz mieć cel biznesowy do następnego Replenishmentu, ale nie musisz. Przedstawiciele biznesu w obu podejściach powinni zapewnić, że zadania do wykonania są wartościowe i w odpowiedniej kolejności, choć obecność „biznesu” na planowaniu kanbanowym jest opcjonalna. Zalecane jest prowadzenie Replenishment Meeting w regularnych odstępach, ale nie trzeba tego robić. Ta elastyczność wydaje się być korzystna, lecz tylko z pozoru. Może być ona źródłem wielu dysfunkcji. Sztywno określone zasady Scruma z jednej strony wprowadzają elementy, które są pewne i redukują przez to złożoność. Z drugiej, stanowi o sile transformacyjnej Scruma. Zdarzyło mi się widzieć niedojrzałe zespoły, które doświadczając frustracji w osiągnięciu Celu Sprintu na Retrospekcji decydowały „o przejściu na Kanbana”, gdyż „tam więcej można”. W momencie, gdy nie ma zasad, potrzeba dojrzałości i dyscypliny wewnątrz zespołu.

Opcjonalnie możemy uznać, że w zależności od okoliczności i potrzeb Replenishment Meeting w dojrzałym Kanbanie może być bardzo podobny, a nawet prawie taki sam jak Sprint Planning w Scrum.

Podsumowanie

Zwięźle i bardzo esencjonalnie odpowiadając na pytanie po co nam Sprint Planning? Potrzebujemy go, gdyż stymuluje nas to do posiadania planu na dostarczenie Celu Sprintu, dzięki czemu jeszcze bardziej podnosimy swoje szanse na sukces. Podczas każdego spotkania zespół weryfikuje wizję i strategię produktu. Dzięki temu Product Owner zbiera pierwszy feedback na temat swoich założeń. Oprócz zaplanowania prac nad produktem planujemy równolegle i ustawiczne usprawnienia procesu wytwórczego. Sposób przeprowadzenia planowania zwiększa podmiotowość i zaangażowanie członków zespołu.

1 komentarz do wpisu “Po co jest Sprint Planning?”

Dodaj komentarz

%d bloggers like this: