Pojęcia, takie jak choćby: Sprint planning, Sprint backlog, Scrum guide, Sprint goal, Product Owner, Scrum team, Sprint valuable, Scrum Master są nierozerwalnie powiązane z metodykami zwinnymi.
Jednym z ważniejszych pojęć - elementów frameworku Scrum - jest Sprint planning. Planowanie Sprintu jest wydarzeniem, które pozwala określić, “co”, “przez kogo” oraz “w jaki sposób” może być zrealizowane w nadchodzącym Sprincie.
Sprinty stanowią podstawę działania większości zespołów projektowych, programistycznych. Są narzędziem, które pozwala zwiększać prawdopodobieństwo osiągania celów.
Cel Sprintu to także wzmocnienie zaangażowania, poprawa koncentracji zespołu, minimalizacja ryzyka pojawienia się sytuacji kryzysowych, krytycznych.
Stąd też ich planowanie jest zadaniem tyleż niezbędnym, co bardzo pożytecznym.
W jaki sposób powinno się planować Sprinty? Jaki jest cel Sprintu? Jak powinno przebiegać takie wydarzenie?
Kto jest odpowiedzialny za planowanie Sprintów? Ile czasu należy poświęcić na zaplanowanie nowego Sprintu?
Czy w ogóle ma sens poświęcanie czasu na takie działania i jakie korzyści mogą one przynieść zespołom pracującym w metodykach zwinnych?
Z takimi właśnie pytaniami będziemy się dziś mierzyć i starać na nie znaleźć odpowiedzi.
Serdecznie zapraszamy do lektury!
Szukasz doświadczonej agencji UX?
Co to jest Sprint?
Wprawdzie o Sprintach pisaliśmy już w osobnym artykule pt. “Czym jest Sprint?”, ale przypomnieć podstawową definicję oraz ideę Sprintu nigdy nie zaszkodzi.
Oficjalny Przewodnik po Scrumie 2020TM definiuje Sprint jako clue Scrumu, jego “serce”, dzięki któremu pomysły zmieniają się w konkretną wartość.
Produkty cyfrowe tworzone w metodykach zwinnych są tworzone właśnie za pomocą Sprintów, które są - mówiąc już bardziej konkretnym językiem - założonym z góry okresem czasu, w którym konkretnie określona praca powinna być wykonana i przekazana do przeglądu.
Należy mocno zasygnalizować, że czas oraz zaplanowana praca wyrażona w formie zadań są wartościami niezmiennymi.
Warte podkreślenia jest także to, że rezultat pracy w danej jednostce czasu nie ma - i mieć nie może - charakteru absolutnego i bezwzględnego.
Stąd też nie pisze się i nie myśli o rezultacie jako o czymś, co “musi się” bezwzględnie wydarzyć w założonych warunkach, a jedynie, co “powinno się” wydarzyć.
O ile oczywiście zespół nie napotka na problemy, które nie pozwolą na zakończenie zaplanowanych zadań.
Każdy Sprint poprzedzony jest celowym spotkaniem planistycznym - Sprint planningiem - podczas którego Product Owner, właściciel produktu, a więc osoba zlecająca pracę i zespół programistyczny uzgadniają dokładnie, jaka praca zostanie wykonana podczas Sprintu.
Sprinty są wydarzeniami, które cechują się:
- stałym czasem trwania
- powtarzalnością
- spójnością
- stałą strukturą, w której można wyróżnić m.in. planowanie Sprintów, codzienny Scrum, retrospektywę Sprintu
- określonym zakresem zadaniowym
- określonym zestawem ról, funkcji, zadań, działań
- określonym celem.
Sprinty następują po sobie i pozwalają na prowadzenie projektu w sposób:
- racjonalny
- przewidywalny
- ustrukturowany
- proceduralny
- kontrolowalny
- konkretny
- zdefiniowany.
Co równie ważne, podczas trwania każdego Sprintu nie wprowadza się żadnych zmian, które zagrażałyby Celowi Sprintu. Zakres pracy jest określony zarówno w czasie, jak również w formie.
Przede wszystkim Sprinty służą:
- lepszej organizacji pracy
- zwiększenia, poprawienia elastyczności projektu
- zmniejszeniu ryzyk
- poprawie adaptacyjności
- zwiększeniu wydajności pracy
- nadaniu odpowiedniego rytmu pracy, dzięki czemu możliwe jest przeciwdziałanie wypaleniu pracowników, zmniejszeniu ich zaangażowania w projekt
- poprawie trafności decyzji.
Z kolei, jak piszą autorzy w Atlassian Agile Coach, Sprinty stanowią esencję metodyk zwinnych, a ich odpowiednie zorganizowanie pozwala przede wszystkim tworzyć produkty cyfrowe - np. aplikacje mobilne, aplikacje webowe - o wiele doskonalsze.
Ponadto, o czym także wspominają ww. autorzy, Sprinty wpływają na atmosferę pracy, emocje towarzyszące tworzeniu oprogramowania, redukują stres i pozwalają tworzyć oprogramowanie z większym spokojem.
Podsumowując: Sprint definiuje się najczęściej jako stosunkowo krótki okres (tygodniowy, dwutygodniowy), w którym zespół projektowy, developerski pracuje nad konkretnie zdefiniowanym celem, w którym zespół ma do wykonania konkretną ilość pracy.
Czym jest planowanie Sprintu?
Wiedząc, czym są i do czego służą Sprinty możemy przejść do kluczowego problemu niniejszego artykułu, mianowicie do definicji planowania Sprintu - Sprint Planning.
Sprint będąc wydarzeniem określonym w czasie, mającym konkretnie zdefiniowany cel musi siłą rzeczy być odpowiednio zaplanowanym wydarzeniem.
Planowanie Sprintu w metodykach zwinnych definiuje się jako etap, zadanie, w którym zespoły decydują, co będzie przedmiotem kolejnego Sprintu, jakie zadania będą wykonywać, jaką porcję pracy wykonają, jakie cele, efekty będą chcieli uzyskać.
Spotkanie, w którym odbywa się planowanie Sprintu najczęściej jest prowadzone przez właściciela produkt (Product Owner) lub Scrum Mastera.
Cel Sprintu, zadania, zakres prac jest określany na podstawie Backlogu Produktu (Product Backlog), który jest po prostu uporządkowaną, ustrukturowaną listą zadań, funkcji lub elementów do wykonania w ramach większego planu.
Mówiąc nieco jeszcze inaczej, Backlog Produktu jest listą, z której jasno powinno wynikać, co jest potrzebne w produkcie i w jakiej kolejności należy dany element dostarczyć, wdrożyć.
Przy czym trzeba pamiętać, że Backlog Produktu powinien być listą kompletną, zawierającą całą pracę, jaką należy wykonać, by stworzyć dany produkt cyfrowy.
Im bardziej doskonały, szczegółowy, konkretny, precyzyjny Backlog, tym lepszy, bardziej racjonalny Sprint Planning.
Backlog Produktu reprezentuje czas, sugeruje ilość tygodni, miesięcy koniecznych na wykonanie produktu cyfrowego. Stąd też podział na mniejsze jednostki organizacji pracy - Sprinty - jest jak najbardziej uzasadniony.
Ważną funkcją Backlogu Produktu - dodajmy na marginesie - jest dzielenie pracy, zadań, na mniejsze części oraz nadawanie im rang - priorytetyzowanie.
Dzięki temu członkowie zespołów są w stanie dostrzec zależności oraz wagę danych części dla całego procesu tworzenia oprogramowania.
Kto tworzy plan Sprintu? Kto określa cel Sprintu?
Choć formalnie za planowanie Sprintu, jak wspomnieliśmy, odpowiedzialni są Product Ownerzy lub Scrum Masterzy to faktycznie nad Sprint Planningiem pracuje cały zespół.
Jest to konieczne, bowiem pozwala na lepsze zrozumienie istoty zadań, zależności poszczególnych elementów, określenie stanu prac.
Służy zatem nie tylko komunikowaniu, wskazywaniu zadań, ale także pozwala uzyskać wspólną perspektywę zespołową.
Pozwala wskazać problemy, jakie zespół natrafia i pozwala je uwzględnić w kolejnym Sprincie.
Jak wygląda spotkanie Sprint planning?
Jak przeprowadzić Sprint Planning? - to pytanie pojawia się nader często. I rzeczywiście do Sprint Planningu należy się odpowiednio przygotwać.
Przeprowadzenie spotkania, które pozwoli rozpocząć nowy Sprint wymaga przede wszystkim:
- odpowiedniego przygotowania wszystkich członków zespołu
- zebrania informacji - Scrum Master powinien w szczególności dysponować odpowiednią wiedzą, informacjami, które pozyskuje od członków zespołu (np. o planowanych urlopach) oraz interesariuszy (którzy mogą, ale z reguły rzadko uczestniczą w wydarzeniach planowania Sprintu)
- zachowania przejrzystości w Backlogu, jego sumiennej, regularnej i częstej aktualizacji
- planu, dzięki czemu nie będzie ono prowadzone w sposób chaotyczny, ale zgodnie z określoną agendą.
Warto pamiętać, że Sprint planning jest także doskonałą okazją do odnowienia w zespole poczucia celu, ustalenia standardów, zgodnie z którymi praca będzie wykonywana.
Wspomniana powyżej agenda spotkania powinna obejmować między innymi część dotyczącą podsumowania postępów prac członków zespołu. Powinna także służyć wyrażeniu problemów, celów oraz obaw.
Przykładowo, niedostępność zasobów, problemy komunikacyjne w zespole, wszelkie przeszkody zewnętrzne i wewnętrzne powinny być omawiane w czasie planowania Sprintu.
Fortunność planowania Sprintu zależna jest także od tego, czy dany zespół ma lidera, który nie tylko pełni taką rolę, ale jest także w ten sposób postrzegany przez członków zespołu.
Rolą liderów jest przede wszystkim:
- zarządzanie planowaniem Sprintu - wskazanie, jaki jest cel Sprintu, który zespół deweloperski powinien osiągnąć
- zarządzanie zdolnościami zespołu
- przeciwdziałanie obciążeniom pracą
- organizowanie pozycji zaległości produktowych.
Podsumowując: spotkanie poświęcone planowaniu Sprintu służy także stworzeniu warunków, środowiska, atmosfery, która wpływa na motywację.
Dzięki planowaniu Sprintu chęć odniesienia sukcesu powinna się stać kolejnym ważnym motywatorem dla członków zespołu oraz zespołu jako takiego.
Jak planować Sprinty?
W planie czasowym, Sprint Planning następuje po retrospektywie Sprintu (szczegółowo pisaliśmy o tym elemencie w artykule pt. “Retrospektywa Scrum”).
Co z punktu widzenia płynności prowadzenia projektu, wydajności jest jak najbardziej zrozumiałe i racjonalne.
Dobrze zaplanowany Sprint powinien obejmować:
- klarownie zdefiniowany cel, który należy określić odpowiadając na pytanie - Co powinno być wykonane, osiągnięte w następnym Sprincie?
- sposoby osiągnięcia celu, strategie działania, które najlepiej określić odpowiadając na pytanie - Jak najlepiej można wykonać daną pracę?
- wskazanie osób, które będą pracowały nad konkretnymi zadaniami, a które najlepiej wskazać odpowiadając na pytanie - Kto powinien wykonać dane zadanie? - co z kolei pozwala uniknąć sytuacji dublowania pracy oraz braku poczucia odpowiedzialności za wykonanie danego zadania.
Każde z powyższych pytań powinno doczekać się odpowiedzi, która będzie dla zespołu pomocna, ale przede wszystkim powinna być to odpowiedź realistyczna. A więc taka, którą zespół jest w stanie wykonać.
Scrum Master wyznacza ogólne ramy, wskazuje cel, ale nie narzuca go odgórnie, tylko wspólnie z zespołem zastanawia się, czy jest on możliwy do osiągnięcia w kolejnym Sprincie.
Właściciel produktu wprawdzie dostarcza, definiuje cel, ale to zespół deweloperski jest w stanie oszacować jego wykonalność.
I tutaj konieczne jest zwrócenie uwagi na bardzo ważny fakt.
By szacowanie było trafne, adekwatne do możliwości zespołu musi być dokonywane w warunkach, w środowisku, w którym panuje atmosfera wzajemnego zaufania.
Przepływ informacji, ocen, predykcji, wątpliwości, uwag, sugestii powinien być niczym nieograniczony i nastawiony na efekt doskonalenia się zespołu, uczenia od siebie. Stąd też należy unikać krytycyzmu, czy oceniania.
W tym wąskim zakresie warto się zastosować do wskazówki, jaką oferują autorzy z Atlassian Agile Coach.
Słusznie zauważają, że szacunki wskazywane przez zespół deweloperski nie mogą być poddawane ocenie, konfrontacji, bowiem wytworzy to bardzo niezdrową atmosferę.
W jej efekcie w kolejnym planowaniu Sprintu szacunki będą albo zawyżone, albo zaniżone i prędzej będą służyć potwierdzeniu nieomylności danego pracownika, jego uczciwości niż zdolności predykcji czasu pracy.
Za osiągnięcie celu Sprintu odpowiedzialny jest cały zespół i tylko zespół jest w stanie odpowiedzieć na pytanie, czy zaproponowany przez Scrum Mastera. Product Ownera cel jest możliwy do osiągnięcia w Sprincie.
Planowanie Sprintu nie jest jednak wróżeniem z fusów, tylko racjonalną procedurą opartą o wyniki ostatniego przyrostu produktu, o możliwości, jakie ma zespół deweloperski.
Sposób osiągnięcia celu Sprintu jest także efektem negocjacji, dyskusji, kompromisu, które pozwalają nie tylko określić warunki możliwości, ale także oszacować konieczny wysiłek.
Warto także podkreślić, że planowanie Sprintu powinno służyć również sprawdzeniu, czy zespół jest kompetencyjnie przygotowany do osiągnięcia danego celu.
W rezultacie Sprint Planning powinien pozwolić zespołowi osiągnąć wspólną perspektywę, przekonanie, co do zakresu prac, sposobów jej wykonania oraz zakresów odpowiedzialności za jej wykonanie.
W ramach Sprint Planningu konieczne jest także podjęcie trzech podstawowych kwestii, mianowicie:
- określenia wagi oraz wartości Sprintu, która wyraża się w pytaniu - Dlaczego Sprint jest cenny?
- określenia, co jest osiągalne w kolejnym Sprincie, która wyraża się w pytaniu - Co można zrobić w kolejnym Sprincie?
- określenia sposobu wykonania pracy, która wyraża się w pytaniu - Jak zostanie wykonana praca?
Określenie ilości pracy wymaga oczywiście posiadania doświadczenia (rozumienia pracochłonności danego zadania), ale także świadomości własnej efektywności, którą zespół powinien także dysponować.
Dobrym podsumowaniem tej części naszym rozważań jest uwaga poczyniona przez autorów piszących dla Atlassian Agile Coach. A ci przestrzegają przed zbyt dogmatycznym podejściem do planowania Sprintów.
Sprint planning powinien być niczym mniej i niczym więcej niż planem, który jednak nie może być dla zespołu ciężarem, ograniczeniem.
Jego rolą jest sprawienie, by zespół był skoncentrowany na wartościowych wynikach. Sprint planning powinien pełnić także rolę parasola ochronnego dla samoorganizacji zespołu.
Korzyści z planowania Sprintu
Wykorzystanie metodyk zwinnych do tworzenia produktów cyfrowych pozwala o wiele efektywniej, racjonalniej, bardziej głęboko i z większą świadomością zarządzać projektami, zespołami.
Planowanie Sprintu, jako ważny element procesu, pozwala o wiele skuteczniej osiągać cele.
W praktyce oznacza to efektywniejsze wykorzystanie:
- czasu
- budżetu
- zasobów
- potencjału poszczególnych członków zespołu oraz zespołu rozumianego jako wartość synergiczna.
Dobrze zaplanowane Sprinty pozwalają także członkom zespołów silniej koncentrować się na celu Sprintu, zadaniach, środkach, narzędziach, wartościach.
Ponadto, Sprint planning pomaga osiągnąć lepszą przejrzystość sytuacji. Przejrzystość oznacza także zdefiniowanie wspólnej dla całego zespołu definicji zakończenia pracy. Kryteria są znane, wspólne, zatem przewidywalne i zrozumiałe.
Wiedząc “co”, “jak”, “kiedy”, “przez kogo” zespoły wiedzą, po prostu, co mają robić, dzięki czemu mogą osiągać założone efekty znacznie szybciej.
Sprint planning. Podsumowanie
- Wykorzystanie metodyk zwinnych do tworzenia produktów cyfrowych pozwala o wiele efektywniej, racjonalniej, bardziej głęboko i z większą świadomością zarządzać projektami, zespołami.
- Sprint definiuje się jako krótki okres, w którym zespół developerski pracuje nad konkretnie zdefiniowanym celem i ma do wykonania konkretną ilość pracy.
- Produkty cyfrowe, tworzone w metodykach zwinnych, są tworzone za pomocą Sprintów, które są założonym z góry okresem czasu, w którym konkretnie określona praca powinna być wykonana i przekazana do przeglądu.
- Sprint planning, planowanie Sprintu jest wydarzeniem, które pozwala na wskazanie celu Sprintu oraz określenie “co”, “przez kogo” oraz “w jaki sposób” ma być zrealizowane w nadchodzącym Sprincie. Członkowie zespołu deweloperskiego wiedzą, co będą robić w trakcie Sprintu, czym będzie wypełniony kolejny Sprint, czym będzie się różnił od bieżącego Sprintu.
- W czasie Sprint planningu Product Owner wraz z zespołem developerskim uzgadniają dokładnie, jaka praca zostanie wykonana podczas Sprintu.
- Sposób osiągnięcia celu jest także efektem negocjacji, dyskusji, kompromisu, które pozwalają nie tylko określić warunki możliwości, ale także oszacować konieczny wysiłek.
- Sprinty następują po sobie i pozwalają na prowadzenie projektu w sposób racjonalny, przewidywalny, ustrukturowany, proceduralny, kontrolowalny, konkretny, zdefiniowany.
- Sprinty służą w dużej mierze lepszej organizacji pracy, zwiększenia, poprawienia elastyczności projektu, zmniejszeniu ryzyk. Podobnie jak daily scrum.
- Sprinty wpływają na atmosferę pracy, emocje towarzyszące tworzeniu oprogramowania, redukują stres i pozwalają tworzyć oprogramowanie z większym spokojem.
- Planowanie Sprintu definiuje się jako etap, w którym zespoły decydują, co będzie przedmiotem kolejnego Sprintu, jakie zadania będą wykonywać, jaką porcję pracy wykonają, jakie cele, efekty będą chcieli uzyskać.
- Fortunność planowania Sprintu zależna jest także od tego, czy dany zespół ma lidera, który nie tylko pełni taką rolę, ale jest także w ten sposób postrzegany przez członków zespołu.
- Dobrze zaplanowany Sprint powinien obejmować klarownie zdefiniowany cel, sposoby osiągnięcia celu, strategie działania oraz zadania oddelegowane do konkretnych osób.
- Planowanie Sprintu jest racjonalną procedurą opartą o wyniki ostatniego przyrostu produktu, o możliwości zespołu programistycznego.
- Sprint planning powinien być niczym mniej i niczym więcej niż planem, który jednak nie może być dla zespołu ciężarem, ograniczeniem.
- Sprint planning pomaga osiągnąć lepszą przejrzystość sytuacji. Przejrzystość oznacza także zdefiniowanie wspólnej dla całego zespołu definicji zakończenia pracy.
- Wiedząc “co”, “jak”, “kiedy”, “przez kogo” zespoły wiedzą, po prostu, co mają robić, dzięki czemu mogą osiągać założone efekty znacznie szybciej.
