Scrum w pigułce

Scrum

Scrum to ramy postępowania (ang. Framework) wykorzystywane w zarządzaniu wytwarzania złożonych produktów. Scrum nie jest procesem, ani techniką wytwórczą, nie jest to też wyczerpujący opis sposobu działania. Scrum definiuje jedynie zbiór ogólnych reguł postępowania w ramach których można stosować różne techniki i procesy. Scrum wykazuje skuteczność stosowanych metod zarządzania produktem oraz sposobów wykonywania pracy, po to aby w sposób ciągły doskonalić środowisko pracy, zespół, a przede wszystkim sam produkt.

Scrum to jedna ze zwinnych (ang. Agile) ram postępowania. Oznacza to, że rozumiane są i stosowane zasady określone w manifeście Agile.

Scrum to: niewielkie zespoły scrumowe oraz związane z nimi role, wydarzenia i artefakty oraz reguły.

Scrum ma charakter iteracyjny, który umożliwia dostarczanie wartości w krótkich (nie dłużej niż miesiąc) odcinkach czasu zwanych sprintami.

Scrum wykorzystuje empiryczną kontrolę procesu tzn. wspomaga zbieranie informacji zwrotnej i reagowanie na nią.  Opiera się ona na trzech filarach: transparentności, inspekcji i adaptacji.

Zasady scrum są proste (opisujący je „Przewodnik po Scrumie” to zaledwie kilkanaście stron) ale ich stosowanie oznacza poważne konsekwencje dla stosującej go organizacji. Uwidacznia on bowiem bardzo szybko problemy i dysfunkcje organizacyjne.

Jednym z filarów empirycznej kontroli jest transparentność, co oznacza iż istotne aspekty procesu muszą być widoczne i zrozumiałe dla wszystkich biorących udział w procesie oraz dla osób odpowiedzialnych za osiągane rezultaty.

Kolejnym filarem jest inspekcja, co oznacza, że stosując scrum należy dokonywać częstych przeglądów artefaktów scrumowych oraz śledzić postępy w realizacji Celu Sprintu.

Adaptacja oznacza, że gdy podczas inspekcji ustalone zostaną rozbieżności, konieczna jest jak najszybsza reakcja, aby jak najszybciej ograniczyć dalsze odstępstwa.

Wartości i filary scrum

Powodzenie w wykorzystaniu scruma zależy od postępowania zgodnie z pięcioma wartościami:

• zaangażowanie (wszyscy członkowie zespołu scrumowego zobowiązują się osiągać wyznaczone cele),
• odwaga (członkowie zespołu scrumowego mają odwagę postępować właściwie i przezwyciężać trudności),
• skupienie (wszyscy skupiają się na sprincie i celach zespołu scrumowego),
• otwartość (zespół scrumowy i interesariusze zgadzają się na pozostawać otwartymi na wszystkie aspekty wykonywanej pracy i związane z nią wyzwania),
• poszanowanie (członkowie zespołu wzajemnie respektują swoje prawo do bycia niezależnymi i kompetentnymi ludźmi).

Zespół scrumowy przyjmując powyższe wartości i postępując zgodnie z nimi powołuje do życia filary scruma:

• transparentność,
• inspekcję,
• adaptację.

Zespół scrumowy (ang. Scrum Team)

Na zespół scrumowy składają się: zespół deweloperski (ang. Development Team), właściciel produktu (ang. Product Owner) oraz Scrum Master. Zespoły scrumowe są międzyfunkcjonalne (ang. cross-functional) co znaczy, że posiadają wszelkie kompetencje niezbędne do ukończenia pracy, nie będąc jednocześnie zależnymi od osób spoza zespołu. Konieczne jest również, aby były samoorganizujące się – a to znaczy, że zespoły same decydują w jaki sposób najlepiej wykonywać daną pracę, nie będąc jednocześnie kierowanymi przez osoby spoza zespołu. Taki model organizacji zespoły pozwala zoptymalizować elastyczność, kreatywność i produktywność. Zespoły scrumowe dostarczają produkty iteracyjni i przyrostowo, co zwiększa szansę na uzyskanie informacji zwrotnej. Taki sposób dostarczania produktu zapewnia ciągłą dostępność działającej i potencjalnie użytecznej wersji produktu.

Samozarządzający się zespół deweloperski jest odpowiedzialny za dostarczenie ukończonego przyrostu produktu na koniec każdego sprintu.

Właściciel produktu odpowiedzialny jest za zarządzanie rozwojem produktu, jego wizji oraz nadawanie priorytetów pracy aby zoptymalizować zysk z inwestycji.

Scrum Master odpowiada za to jak zespół pracuje, za efektywne działanie całego systemu poprzez wsparcie zespołu deweloperskiego i właściciela produktu, zapewnienie transparentności pracy i krzewienie wiedzy.

Właściciel produktu (ang. Product Owner)

Odpowiada za maksymalizację wartości produktu oraz pracy zespołu deweloperskiego. Sposoby osiągania tych celów mogą znacznie różnic się pomiędzy organizacjami, zespołami i poszczególnymi osobami.

Właściciel produktu jest jedyną osobą odpowiedzialną za rejestr produktu (Product Backlog) i zarządzanie nim. W zakresie tej odpowiedzialności mieści się:

• klarowne artykułowanie elementów rejestru produktu
• porządkowanie kolejności realizacji elementów rejestru, aby osiągnąć jak najbardziej efektywnie założone cele,
• optymalizowanie wartości pracy zespołu deweloperskiego
• zapewnienie dostępności rejestru produktu dla wszystkich, jego klarowności i przejrzystości
• zapewnienie zrozumienia elementów rejestru produktu przez zespół deweloperski na każdym, etapie ich realizacji.

Właściciel produktu to zawsze jedna osoba, a nie komitet. Właściciel produktu może reprezentować interesy wszystkich zainteresowanych (klienta, kadry zarządzającej), lecz tylko on osobiście może zmieniać priorytety elementów rejestru produktu. To do niego trzeba się zwrócić w sprawie jakichkolwiek zmian w tym scrumowym artefakcie.

Właściciel produktu może wykonywać swoje zadania samodzielnie albo zlecać je zespołowi deweloperskiemu, ale zawsze pozostaje za nie odpowiedzialny.

Zespół deweloperski (ang. Development Team)

Zespół deweloperski (ang. Development Team) składa się ze specjalistów, odpowiedzialnych za dostarczenie, na koniec każdego sprintu, ukończonego i gotowego do potencjalnego wydania przyrostu (ang. Increment) produktu. Przyrost jest akceptowany podczas przeglądu sprintu (ang. Sprint Review). To właśnie członkowie zespołu deweloperskiego tworzą Przyrost. 

Zespół deweloperski jest samoorganizujący się i interdyscyplinarny. Co to oznacza? Samoorganizujący się oznacza, że jest on uprawniony przez organizację do samodzielnego organizowania własnej pracy i zarządzania nią. Rezultatem takiego postępowania jest synergiczne zwiększenie wydajności i efektywności zespołu. Interdyscyplinarny (ang. cross-functional) oznacza, że członkowie zespołu mają łącznie wszystkie kompetencje, niezbędne do wytworzenia przyrostu produktu. Nie oznacza to oczywiście, że każdy członek zespołu musi umieć wszystko, ale że zespół jako całość ma kompetencje wystarczające do dostarczenia przyrostu. W zespole nie wyróżnia się poszczególnych ról (np. programista, tester, projektant itp.). Każdy z członków zespołu jest deweloperem. Cały zespół jest odpowiedzialny za osiągnięcie wspólnego celu.

Jak duży powinien być zespół deweloperski? Powinien być on na tyle liczny by móc wykonać założoną pracę, ale jednocześnie na tyle mały, aby pozostać zwinnym. Mniej niż trzech członków zespołu oznacza mały stopień interakcji i niższą produktywność. Łatwiej też w takim zespole o braki kompetencyjne. Jednocześnie więcej niż dziewięciu członków zespołu to spore nakłady na koordynację pracy. W dużych zespołach złożoność wzrasta na tyle, że stosowanie procesu empirycznego przestaje być użyteczne. Osoby właściciela produktu i Scrum Mastera nie wliczają się do tego ograniczenia. 

Zespół pracuje nad elementami rejestru produktu i musi się ze sobą komunikować. Dlatego niezwykle istotne jest, aby zespół gdy tylko jest to możliwe - pracował w jednej lokalizacji. I mowa tu o wspólnym pokoju, a nie tylko budynku. Dzięki wspólnej przestrzeni łatwiej wymienia się informacje, buduje zaufanie i tożsamość zespołu. Nie oznacza to, że nie można tworzyć rozproszonych zespołów, ale należy przyjąć że ich praca - utrudniona przez konieczność stosowania dodatkowych, najczęściej elektronicznych środków komunikacji – może być mniej efektywna.

Scrum Master

Scrum Master odpowiada za wspieranie i promowanie stosowania scruma. Osiąga to poprzez pomaganie wszystkim w zrozumieniu teorii scruma, jego praktyk, reguł i wartości.

Scrum Master jest przywódcą służebnym (ang. servant leader), pomaga nie tylko zespołowi scrumowemu, ale i całej organizacji zrozumieć, które interakcje z zespołem są pomocne, a które nie. Scrum Master pomaga zmieniać te zachowania w sposób pozwalający na maksymalizację wartości wytwarzanej przez zespół scrumowy.

Scrum Master wspiera właściciela produktu i służy mu pomocą w wielu aspektach:

• zapewnia, że cel, zakres i domena produktu są zrozumiałe dla wszystkich w zespole, tak dobrze, jak to tylko możliwe.
• znajduje techniki efektywnego zarządzania rejestrem produktu,
• pomaga zespołowi zrozumieć potrzebę formułowania zwięzłych i jasnych elementów rejestru produktu,
• pomaga w rozumieniu zasad planowania produktu w środowisku empirycznym,
• zapewnia, że właściciel produktu wie jak uporządkować rejestr produktu, by zmaksymalizować wartość,
• pomaga w zrozumieniu i praktykowaniu zwinności (ang. agility)
• wspomaga przebieg wydarzeń scrumowych, kiedy jest o to proszony i kiedy jest to niezbędne.

Scrum Master służy pomocą zespołowi deweloperskiemu na wiele sposobów:

• wspiera zespół deweloperski w zakresie stosowania zasad samoorganizacji i międzyfunkcyjności,
• pomaga zespołowi deweloperskiemu tworzyć produkty o wysokiej wartości,
• usuwa przeszkody przeszkadzające zespołowi deweloperskiemu w osiągnięciu celu,
• wspomaga przebieg wydarzeń scrumowych, kiedy jest o to proszony lub, gdy jest to konieczne,
• trenuje Zespół Deweloperski w zakresie sposobu wykonywania pracy w organizacjach, w które są w trakcie transformacji scrumowej.

Scrum Master wspiera całą organizację wieloma metodami:

• przewodzi procesom wdrażania scruma i prowadzi coaching osób zaangażowanych w ten proces,
• planuje wykorzystanie scruma wewnątrz organizacji,
• wspiera interesariuszy oraz wszystkich pracowników w rozumieniu i stosowaniu scruma oraz empirycznego podejścia do tworzenia i rozwoju produktu,
• inicjuje i wspiera zmiany prowadzące do zwiększenia produktywności zespołu scrumowego,
• współpracuje z innymi Scrum Masterami w celu zwiększenia efektywności wykorzystania scruma w organizacji.

Wydarzenia scrumowe (ang. Scrum Events)

Wydarzenia scrumowe (ang. Scrum Events) wprowadzają regularność i ograniczają potrzebę wprowadzania innych spotkań. Wszystkie wydarzenia scrumowe są ograniczone czasowo (ang. timebox), oznacza to iż przewidziany jest dla nich maksymalny czas trwania.

Po ustaleniu długości sprintu, jego czas trwania pozostaje stały, nie wolno go wydłużać, ani skracać. Pozostałe wydarzenia mogą zakończyć się, kiedy ich cel zostanie osiągnięty, ale nie mogą trwać dłużej niż standardowe ramy czasowe przewidziane we frameworku.

Ograniczenia czasowe dla wydarzeń scrumowych wyglądają następująco:

Sprint - miesiąc (lub 4 tygodnie), dwa tygodnie, tydzień;

Codzienny scrum (ang. Daily Scrum) - 15 minut;

Planowanie sprintu (ang. Sprint Planning) - 8 godzin (dla sprintu trwającego 4 tygodnie), lub krócej (dla krótszych sprintów);

Przegląd sprintu (ang. Sprint Review) - 4 godziny (dla 4 tygodniowego sprintu) lub proporcjonalnie mniej (dla krótszych sprintów);

Retrospektywa sprintu (ang. Sprint Retrospective) - 3 godziny (dla 4 tygodniowego sprintu) lub krócej (dla sprintów o mniejszej długości).

Wprowadzenie ograniczeń czasowych na wydarzenia scrumowe przeciwdziała marnotrawieniu czasu i zapewnia jego właściwe wykorzystanie.

Poza sprintem, który obejmuje wszystkie pozostałe wydarzenia, każde z wydarzeń jest okazją do przeprowadzenia inspekcji oraz dokonania adaptacji. Wydarzenia scrumowe zapewniają transparentność, brak któregokolwiek z nich powoduje utratę szansy na przeprowadzenie inspekcji i adaptacji.

Sprint

Sprint jest sercem scruma – jego długość to maksymalnie miesiąc. W trakcie trwania sprintu wytwarzany jest „ukończony”, gotowy do użycia i wydania przyrost produktu. Sprinty mają stałą długość przez czas trwania prac. Nowy sprint zaczyna się natychmiast po zakończeniu poprzedniego.

Sprinty składają się z planowania sprintu, pracy wytwórczej, codziennych scrumów, przeglądu sprintu i retrospektywy sprintu.

Podczas trwania sprintu nie wprowadza się zmian, które mogłyby zagrozić realizacji celu sprintu, nie obniża się celów jakościowych, jednakże wraz ze zdobywaniem nowej wiedzy zakres prac może być wyjaśniany i renegocjowany pomiędzy właścicielem produktu a zespołem deweloperskim.

Każdy sprint może być postrzegany jako projekt niesięgający w wprzód dalej niż 1 miesiąc. Jak każdy projekt, sprint zmierza do osiągnięcia rezultatu, którym jest cel sprintu. Z każdym sprintem łączy się opis tego, co należy zbudować wraz z projektem i planem jak to zrobić, aby powstał oczekiwany przyrost produktu.

Długość sprintu ograniczona jest do miesiąca kalendarzowego. Gdyby termin ten był bardziej odległy, mogłaby zmienić się definicja tego co ma zostać zrealizowane, co zwiększyłoby złożoność oraz ryzyko przedsięwzięcia. Sprint wprowadza przewidywalność, zapewniając proces inspekcji i adaptacji w dążeniu do osiągnięcia celu sprintu. Sprint ogranicza ryzyko poniesionych kosztów do maksimum jednego miesiąca kalendarzowego.

Sprint może zostać przerwany przed upływem ograniczenia czasowego, ale tylko właściciel produktu może o tym zdecydować. Decyzję tę może on podjąć pod wpływem opinii interesariuszy, Scrum Mastera lub zespołu deweloperskiego. Zdarzyć się tak może, gdy cel sprintu się zdezaktualizuje np. gdy firma wybierze inny kierunek rozwoju lub zmienią się uwarunkowania technologiczne lub rynkowe. Podsumowując: sprint może zostać przerwany, gdy kontynuowanie prac nie ma sensu w zaistniałej sytuacji. Ze względu na krótki czas trwania sprintów są one przerywane niezwykle rzadko.

Gdy sprint zostanie przerwany, wszystkie ukończone elementy rejestru produktu są przeglądane. Jeżeli część tej pracy nadaje się do wydania, zwykle jest ona akceptowana przez właściciela produktu. Nieukończone elementy rejestru produktu są ponownie szacowane i wracają do rejestru produktu.

Przerwanie sprintu to marnowanie zasobów, ponieważ zachodzi konieczność przegrupowania, kolejnego planowania aby móc rozpocząć kolejny sprint. Przerwanie sprintu jest traumatycznym wydarzeniem dla zespołu, dlatego stosuje się je bardzo rzadko.

Planowanie sprintu (ang. Sprint Planning)

Praca do wykonania w trakcie Sprintu jest określana podczas planowania sprintu (ang. Sprint Planning). Plan ten powstaje jako wynik wspólnej pracy zespołu scrumowego.

Planowanie trwa maksimum 8 godzin, gdy zespół pracuje w miesięcznych sprintach. Dla krótszych sprintów czas ten jest krótszy (na ogół proporcjonalnie). Zadanie Scrum Mastera polega na zapewnieniu, że planowanie się odbywa, a jego uczestnicy rozumieją jego cel. Scrum Master uczy zespół zachowania ram czasowych tego wydarzenia.

Planowanie składa się z 2 części:

Część pierwsza: Co może zostać dostarczone w bieżącym sprincie?

Zespół deweloperski prognozuje zakres prac, które zostaną wykonane podczas sprintu. Właściciel produktu określa założenia sprintu i omawia te elementy rejestru produktu, które trzeba zrealizować, aby osiągnąć cel sprintu. Cały zespół scrumowy jest odpowiedzialny za dostarczenie przyrostu produktu i dlatego wspólnie pracuje nad zrozumieniem zakresu prac, które są do wykonania w sprincie. Właściciel produktu musi wiedzieć, co jest najważniejsze, a zespół – ile z tego jest w stanie zrobić w trakcie bieżącego sprintu.

Planowanie prowadzi się w oparciu o ostatni przyrost produktu (ang. Product Increment) oraz rejestr produktu, a także na przewidywanych możliwościach zespołu deweloperskiego (na podstawie archiwalnych rezultatów zespołu). O tym ile elementów z rejestru produktu zostanie włączonych do rejestru sprintu (ang. Sprint Backlog) decyduje wyłącznie zespół deweloperski. Tylko on jest w stanie ocenić, jakie zadania jest w stanie zrealizować podczas trwania sprintu.

W trakcie planowania zespół tworzy cel sprintu. Pomaga on zespołowi zrozumieć, w jakim celu tworzony będzie przyrost produktu. Osiągnięcie celu zostanie zrealizowane poprzez implementację elementów wybranych do rejestru sprintu.

Część druga: W jaki sposób praca, niezbędna do dostarczenia przyrostu, będzie wykonana?

Po ustaleniu celu sprintu, zespół decyduje, w jaki sposób elementy wybrane do rejestru sprintu zostaną przekształcone w “ukończony” przyrost produktu.

Zespół deweloperski na ogół rozpoczyna od projektowania systemu i wstępnego zarysowania prac niezbędnych do zamiany elementów rejestru sprintu w działający przyrost produktu. Zdarza się, że ostatecznie ilość pracy niezbędnej do wykonania odbiega od prognozowanej, jednakże coraz bardziej doświadczony zespół będzie mógł realizować szacowania trafniej wraz ze wzrostem swojej wiedzy, na podstawie danych historycznych.

W trakcie tego zdarzenia praca jest planowana na kilka pierwszych dni sprintu i rozpisywana na mniejsze porcje (zadania), często mniejsze niż jeden dzień roboczy. Zespół deweloperski samodzielnie rozdziela pracę do wykonania, zarówno podczas planowania, jak i w trakcie trwania sprintu.

Właściciel produktu może pomóc wyjaśniać niektóre elementy rejestru produktu oraz uzyskiwać kompromis. Jeżeli zespół deweloperski określi, że ma zbyt mało lub za dużo pracy, może renegocjować zakres pracy z właścicielem produktu. Zespół deweloperski może również zaprosić na planowanie inne osoby, aby wsparły go wiedzą domenową i techniczną.

Zanim zakończy się planowanie sprintu, zespół powinien potrafić wytłumaczyć zarówno właścicielowi, jak i Scrum Masterowi, w jaki sposób chce pracować, samodzielnie się organizując, aby osiągnąć cel sprintu wytwarzając działający przyrost produktu.

Codzienny scrum (ang. Daily Scrum)

Codzienny Scrum (ang. Daily Scrum), to wydarzenie dla zespołu deweloperskiego, które jest ograniczone do 15 minut. Codzienny scrum organizowany jest każdego dnia sprintu, aby zaplanować pracę na najbliższe 24 godziny. W ten sposób poprzez inspekcję pracy wykonanej wczoraj, zespół prognozuje pracę na dzień bieżący, optymalizując współpracę między członkami zespołu i ich efektywność. Aby uprościć organizację, codzienny scrum odbywa się zawsze w tym samym miejscu, o stałej porze.

Codzienny scrum daje zespołowi deweloperskiemu możliwość oceny postępu prac nad realizacją celu sprintu oraz zwiększa szansę na jego osiągnięcie. Każdego dnia zespół deweloperski analizuje w którym miejscu na drodze do celu sprintu się znajduje i jak ona przebiegać będzie w kolejnych dniach. Dzięki temu wie, jak musi współpracować, aby wytworzyć przyrost produktu przed końcem sprintu.

Przebieg wydarzenia ustalany jest przez zespół deweloperski. Scrum Master zapewnia, że zespół spotyka się codziennie i jego uczestnicy rozumieją jego cel. Uczy on zespół, aby spotkanie zamykało się w 15 minutach.

Niektóre zespoły wykorzystują pytania, inne prowadzą dyskusje.

Przykład trzech pytań które można zastosować podczas tego spotkania:

• Co zrobiłem wczoraj, co pomogło zespołowi deweloperskiemu przybliżyć się do osiągnięcia celu sprintu?
• Co zrobię dzisiaj, co pomoże zespołowi deweloperskiemu przybliżyć się do osiągnięcia celu sprintu?
• Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub zespołowi deweloperskiemu osiągnięcie celu sprintu?

Codzienny scrum jest spotkaniem wewnętrznym zespołu deweloperskiego. Jeżeli inne osoby są obecne, Scrum Master dba, aby nie zaburzały one jego przebiegu.

Codzienny scrum eliminuje inne spotkania, poprawia komunikację, pozwala identyfikować przeszkody, które mogą być szybko i efektywnie usuwane. Taka forma spotkań sprzyja szybkiemu podejmowaniu decyzji i podnosi poziom wiedzy zespołu deweloperskiego. Jest to kluczowy element procesu inspekcji i adaptacji.

Przegląd sprintu (ang. Sprint Review)

Przegląd sprintu (ang. Sprint Review) jest organizowany na koniec sprintu w celu przeprowadzenia inspekcji przyrostu i o ile zajdzie taka potrzeba, dostosowania rejestru produktu. Podczas przeglądu sprintu, zespół wraz z interesariuszami analizują to co zostało ukończone w sprincie. Następnie uczestnicy rozważają, co mogłoby zostać wykonane w następnej kolejności, aby zoptymalizować wartość. Przegląd sprintu ma charakter nieformalny i ma na celu pobudzenie współpracy i uzyskanie informacji zwrotnej (ang. feedback).

Dla miesięcznego sprintu, przegląd trwa 4 godziny, dla krótszego mniej. Rolą Scrum Mastera jest zapewnienie, że spotkanie się odbywa i jego uczestnicy rozumieją jego cel. Scrum Master uczy wszystkie zebrane osoby jak zmieścić się w wyznaczonych ramach czasowych.

Podczas przeglądu sprintu obecni są zespół scrumowy oraz kluczowi interesariusze zaproszeni przez właściciela produktu.

Przegląd sprintu obejmuje następujące elementy:

• Wyjaśnienie przez właściciela produktu, które elementy backlogu produktu zostały „ukończone”, a które nie.
• Omówienie przez zespół deweloperski, co poszło dobrze w trakcie sprintu, jakie napotkano problemy oraz jak te problemy rozwiązano.
• Prezentacja przez zespół deweloperski  „ukończonej” pracy wraz z odpowiedziami na pytania dotyczące przyrostu.
• Omówienie rejestr produktu przez właściciela produktu w jego bieżącej postaci. Jeśli zachodzi taka potrzeba, przewidywany jest prawdopodobny termin zakończenia prac, przy wzięciu pod uwagę dotychczasowo wykonanej pracy.
• Wspólne omówienie kolejnych kroków. W ten sposób przegląd sprintu dostarcza wartościowego wkładu w następujące po nim planowanie sprintu.
• Przegląd tego, jak rynek lub potencjalne zastosowanie produktu mogły się zmienić i co w tej sytuacji jest najbardziej wartościową rzeczą do zrobienia.
• Rewizja czasu realizacji, budżetu, potencjalnych możliwości i uwarunkowań rynkowych dla kolejnego przewidywanego wydania produktu.

Retrospektywa Sprintu (ang. Sprint Retrospective)

Retrospektywa Sprintu (ang. Sprint Retrospective) to okazja dla zespołu do przeprowadzenia inspekcji swoich działań i opracowanie planu usprawnień, który zostanie wcielony w życie w kolejnym sprincie.

Retrospektywa ma miejsce po przeglądzie sprintu, przed kolejnym planowaniem sprintu. Trwa ona nie dłużej niż 3 godziny dla miesięcznych sprintów (dla krótszych oczywiście krócej). Scrum Master zapewnia, że wydarzenie się odbywa i wszyscy uczestnicy znają i rozumieją jego cel.

Scrum Master dba, aby spotkanie to przebiegło w pozytywnej atmosferze i było efektywne. Uczy też uczestników zachowania ram czasowych. Scrum Master uczestniczy w retrospektywie jako zwykły członek zespołu z perspektywy odpowiedzialności za realizację zasad scrum.

Cele retrospektywy:

• analiza tego, co wydarzyło się w ostatnim sprincie, biorąc pod uwagę ludzi, relacje, proces i narzędzia,
• rozpoznanie i uporządkowanie ważnych elementów, które sprawdziły się w działaniu oraz tych, które kwalifikują się do usprawnienia,
• utworzenie planu wprowadzania w życie usprawnień w sposobie wykonywania pracy przez zespół scrumowy.

W trakcie spotkania, zespół scrumowy powinien zidentyfikować usprawnienia, które planuje wprowadzić w kolejnym sprincie. Realizacja tych usprawnień w kolejnych sprintach jest przejawem adaptacji, która nastąpiła jako efekt autoinspekcji zespołu scrumowego.

Scrum Master zachęca członków zespołu scrumowego do wdrażania usprawnień, w ramach scruma, stosowanych przez zespół procesu i praktyk wytwórczych tak, aby w kolejnym sprincie praca była bardziej efektywna i dawała więcej satysfakcji. Podczas każdej retrospektywy sprintu zespół scrumowy tworzy plan, podniesienia jakości produktu poprzez usprawnienie pracy i dostosowanie definicji „ukończenia”. Robi to w taki sposób by było to odpowiednie i nie stało w konflikcie z wytwarzanym produktem i wytycznymi organizacji.

Retrospektywa sprintu jest formalnym elementem scruma, całkowicie skoncentrowanym na procesie inspekcji i adaptacji.

Artefakty scruma (ang. Scrum Artefacts)

Artefakty scruma (ang. Scrum Artefacts) stanowią reprezentację wartości i pracy w celu uzyskania transparentności i stworzenia okazji do inspekcji i adaptacji. Mają one zwiększać dostępność i czytelność kluczowych informacji w taki sposób, aby wszyscy zainteresowani rozumieli wszystkie informacje w taki sam sposób.

Wyróżniamy trzy artefakty:

• rejestr produktu (ang. Product Backlog),
• rejestr sprintu (ang. Sprint Backlog),
• przyrost (ang. Increment).

Scrum opiera się na transparentności. W oparciu o obserwowany stan artefaktów  podejmowane są decyzje celu optymalizacji wartości i minimalizacji ryzyka. Stopień transparentności ma więc znaczący wpływ na nie. Niepełna przejrzystość artefaktów prowadzić może do błędnych decyzji, wzrostu ryzyka oraz obniżeniu wartości.

Zespół scrumowy (Scrum Master, właściciel produktu oraz zespół deweloperski) pracuje wraz z pozostałymi zainteresowanymi stronami w celu ustalenia czy artefakty są transparentne dla wszystkich. Są różne sposoby radzenia sobie z brakiem pełnej transparentności i Scrum Master musi pomagać w doborze praktyk najbardziej adekwatnych do konkretnej sytuacji. Scrum Master pomaga identyfikować niepełną transparentność poddając artefakty inspekcji, będąc wyczulonym na powtarzalność wydarzeń i zachowań, słuchając uważnie tego o czym się rozmawia. Wyłapuje on różnice pomiędzy oczekiwaniami a rzeczywistymi wynikami.

Zadanie Scrum Mastera polega na pracy nie tylko z zespołem, ale z całą organizacją w celu zwiększenia transparentności artefaktów. Zazwyczaj praca ta polega na dowiadywaniu się, przekonywaniu i inicjowaniu zmiany. Transparentność nie pojawia się ad hoc - jest drogą.

Rejestr produktu (ang. Product Backlog)

Rejestr produktu (ang. Product Backlog) to uporządkowana lista wszystkiego, co w danym momencie wiadomo o stanie i rozwoju produktu. Jest on jedynym źródłem wymaganych zmian, które mają być wprowadzone w produkcie. Osobą odpowiedzialną za rejestr produktu jest właściciel produktu. Odpowiada on za treść poszczególnych elementów rejestru, ich dostępność oraz kolejność.

Praca nad rejestrem produktu nigdy się nie kończy. Nigdy nie jest on skończony i zamknięty. Jego początkowa wersja określa najwcześniej znane i najlepiej zrozumiane wymagania. Ewoluuje on wraz z produktem i środowiskiem w którym będzie on stosowany. Rejestr produktu zmienia się dynamicznie dostosowując się do warunków rynkowych. Konieczne jest uwzględnienie zmian w tych aspektach produktu, które zapewnią jego dopasowanie, konkurencyjność i użyteczność. Rejestr produktu funkcjonuje tak długo, jak istnieje produkt.

Rejestr produktu to lista wszystkich funkcji, cech, wymagań, zmian i ulepszeń, które reprezentują zmiany które będą wprowadzane do produktu w jego przyszłych wydaniach. Elementy rejestru produktu mają następujące atrybuty: opis, kolejność, wartość i oszacowanie. Często również elementy rejestru produktu zawierają opis testu dowodzącego ich wykonanie i kompletność zgodnie z definicją “ukończenia”.

Wraz z używaniem produktu i wzrostem jego wartości, otoczenie rynkowe dostarcza informacji zwrotnej, a rejestr produktu staje się coraz dłuższą i wyczerpującą listą. Wymagania zmieniają się w sposób ciągły, rejestr produktu jest więc żywym artefaktem. Zmiany w sytuacji rynkowej i wymaganiach biznesowych oraz technologii mają odbicie w zmianach elementów rejestru produktu.

Często zdarza się iż nad produktem pracuje wspólnie więcej niż jeden zespół scrumowy. Wówczas do opisywania przyszłej pracy nad produktem stosowany jest tylko jeden rejestr produktu. W takim przypadku można stosować dodatkowy atrybut grupujący elementy rejestru produktu.

Doskonalenie (ang. Refinement) rejestru produktu jest działaniem polegającym na uszczegóławianiu, szacowaniu i porządkowaniu elementów rejestru. Jest to proces ciągły, w trakcie którego właściciel produktu wraz z zespołem deweloperskim opracowują szczegóły elementów rejestru. Elementy rejestru są przeglądane i korygowane. Sposób i czas prowadzenia doskonalenia zależy od zespołu scrumowego, jednak zazwyczaj przyjmuje się iż proces ten nie powinien zabierać więcej niż 10% czasu trwania sprintu. Nie zmienia to faktu, że uaktualnianie może mieć miejsce w każdej chwili za zgodą lub bezpośrednio przez właściciela produktu.

Elementy rejestru produktu znajdujące się na początku listy są zwykle bardziej klarowne i bardziej szczegółowo opisane niż te z końca listy. W oparciu o zwiększoną czytelność i większą liczbę szczegółów przygotowywane są bardziej precyzyjne oszacowania. Im niżej w rejestrze, tym mniej szczegółów. Elementy przewidziane na najbliższy sprint mają taką wielkość i szczegółowość aby każdy z nich mógł zostać “ukończony” w pojedynczym sprincie. Elementy rejestru produktu, które mogą zostać ukończone przez zespół deweloperski w jednym sprincie, są uznawane za “przygotowane” do rozważenia podczas planowania sprintu. 

Zespół deweloperski jest odpowiedzialny za wszystkie oszacowania. Właściciel produktu może wpływać na zespół, pomagać dostrzegać możliwe kompromisy i podejmować decyzje, ale pracę szacują te osoby, które będą je wykonywać.

Rejestr sprintu (ang. Sprint Backlog)

Rejestr sprintu (ang. Sprint Backlog) to zbiór elementów rejestru produktu, które zostały wybrane do realizacji w bieżącym sprincie. Są one rozszerzone o plan dostarczenia przyrostu produktu i realizacji celu sprintu. Poprzez rejestr sprintu zespół prognozuje, które funkcjonalności zostaną włączone do kolejnego przyrostu i jaką pracę trzeba wykonać aby te funkcjonalności dostarczyć w postaci “ukończonego” przyrostu.

Rejestr sprintu to obraz całej pracy niezbędnej w oczach zespołu deweloperskiego do osiągnięcia celu sprintu. Aby zapewnić ciągłe udoskonalanie się, rejestr sprintu zawiera przynajmniej jedno istotne usprawnienie rozpoznane w poprzedniej retrospektywie.

Rejestr sprintu jest planem na tyle szczegółowym, aby postępy prac były zrozumiałe podczas codziennego scruma. Rejestr sprintu jest modyfikowany przez zespół deweloperski na bieżąco podczas trwania sprintu. To uszczegóławianie zachodzi w konsekwencji realizacji kolejnych elementów planu, gdy zespół dowiaduje się coraz więcej na temat pracy, która jest niezbędna do osiągnięcia celu sprintu. 

W przypadku konieczności wykonania dodatkowej pracy, zespół deweloperski dodaje ją do rejestru sprintu. W miarę kończenia poszczególnych elementów, aktualizowane jest oszacowanie pozostałej do wykonania pracy. Zbędne elementy planu są usuwane. Tylko zespół deweloperski może zmieniać swój rejestr sprintu w trakcie trwania sprintu. Rejestr sprintu jest dobrze widocznym, transparentnym, odzwierciedlającym rzeczywistość, uaktualnianym na bieżąco obrazem pracy zespołu, jaki planowany jest do realizacji w trakcie sprintu. Wyłącznym właścicielem rejestru sprintu jest zespół deweloperski.

W każdym momencie sprintu, cała praca pozostała do wykonania może zostać podsumowana. Zespół robi to przynajmniej raz dziennie - podczas codziennego scruma. Zespół deweloperski obserwuje zmiany ilości pracy pozostałej do wykonania i na tej podstawie określa prawdopodobieństwo realizacji celu sprintu. Poprzez codzienny monitoring pozostałej do wykonania pracy, zespół zarządza jej postępami.

Przyrost produktu

Przyrost produktu (ang. Increment) jest sumą wszystkich elementów rejestru produktu ukończonych podczas bieżącego sprintu wraz z wartością wszystkich poprzednich sprintów. Przyrost musi być “ukończony” zgodnie z definicją “ukończenia” zespołu scrumowego i gotowy do użycia. Przyrost to namacalny efekt wykonanej w trakcie sprintu pracy, podlegający empirycznej inspekcji na jego końcu. Reprezentuje on krok w kierunku celu bądź wizji. Przyrost musi być gotowy do użycia, niezależnie od decyzji o jego wydaniu, która należy ostatecznie do właściciela produktu.

Definicja “ukończenia” (ang. Definition of Done, DoD)

Definicja “ukończenia” (ang. Definition of Done, DoD) określa, kiedy element rejestru produktu lub przyrost uznajemy za “ukończony”. Definicja ta musi być zrozumiała dla wszystkich uczestników procesu. Pomimo że różne zespoły definiują ten stan w różny sposób, kluczowe jest, aby wszyscy członkowie zespołu rozumieli, co oznacza stwierdzenie że praca został ukończona. 

To właśnie klarowna i zrozumiała definicja "ukończenia" pomaga zespołowi w określeniu, ile i które elementy rejestru produktu można wybrać do realizacji w bieżącym sprincie podczas planowania sprintu. Celem sprintu jest bowiem dostarczenie przyrostu - gotowej do wydania funkcjonalności zgodnej z aktualną definicją “ukończenia”.

Przyrost funkcjonalności produktu jest dostarczany w każdym sprincie. Musi być on gotowy do użycia, aby właściciel produktu mógł zadecydować o jego wydaniu. Kiedy definicja “ukończenia” jest elementem przyjętych standardów lub wytycznych stosowanych przez organizację wytwarzająca oprogramowanie, wszystkie zespoły scrumowe muszą traktować je jako podstawę - niezbędne minimum i się jej podporządkować. 

Jeżeli definicja “ukończenia” nie jest elementem standardu organizacji, zespół deweloperski musi opracować definicję “ukończenia” właściwą dla wytwarzanego przez zespół produktu. Gdy nad produktem pracuje wiele zespołów, muszą mieć one wspólną, uzgodnioną definicję “ukończenia”.

Każdy przyrost jest rozszerzeniem wszystkich poprzednich przyrostów i jest dokładnie przetestowany w celu zapewnienia, że wszystkie one działają razem jako całość.

W miarę nabywania doświadczenia przez zespoły scrumowe, oczekuje się iż definicja “ukończenia” zawierać będzie coraz bardziej rygorystyczne kryteria, coraz wyższej jakości. Nowe wersje tej definicji mogą ujawniać pracę niezbędną do wykonania na poprzednio “ukończonych” przyrostach.