Skoro postanowiliśmy pracować Scrumem, zaplanowaliśmy Sprint i jego cel, a potem aktualizowaliśmy nasz plan w oparciu o Daily, pora sprawdzić, jak nam poszło. Dzisiaj zatem pochylimy się nad Przeglądem Sprintu, częściej nazywanym z angielska Sprint Review.

KIEDY?

Skoro w spotkaniu tym chodzi o sprawdzenie, co nam się udało dokonać, to oczywiście przegląd musi się odbyć na zakończenie Sprintu. Po nim powinna odbyć się Retrospektywa Sprintu (ostatnie spotkanie, o którym będzie mowa później) i już kolejny Sprint zaczyna się Planowaniem Sprintu. W praktyce zespoły bardzo często stają przed dylematem, jak odczytywać wskazówkę ze Scrum Guide dotyczącą terminu spotkania. Zdarza się, że spotkania na koniec Sprintu odbywają się z różnych względów koło południa lub wcześniej, natomiast Planowanie dopiero rano następnego dnia. Implikuje to pytania, co robić pomiędzy Review i Retrospektywą, które kończą się np. o 14, a Planowaniem. Czy to jakiś niesprecyzowany czas między Sprintami, czy to złamanie zasad ze Scrum Guide’a, czy wtedy możemy pracować, jeśli tak, to nad czym, a jeśli nie, to co mamy robić? Odpowiedziałabym, że przede wszystkim powinniśmy kierować się zdrowym rozsądkiem. Jeśli nie udało nam się wykonać w Sprincie całej pracy, ale zostało jej tak niewiele, że przez te kilka godzin jesteśmy w stanie ją ukończyć, zróbmy to. W takim przypadku zespoły często symbolicznie zamykają Sprint dopiero na początku Planowania, żeby przez ten czas też mieć wgląd w tablicę i kończone prace. Jeśli natomiast wszystkie zadania ze Sprintu mamy wykonane, być może warto sięgnąć do Backlogu Produktu po jakiś mały błąd, czy zadanie utrzymaniowe (oczywiście kierując się wartością, jaką możemy dzięki temu zadaniu uzyskać). Jednocześnie, jeśli nie chcemy pracować nad dodatkowymi zadaniami, czas ten możemy spokojnie przeznaczyć na poszerzanie swojej wiedzy, zgłębianie dodatkowych zagadnień, wymianę doświadczeń i inne aktywności, które zaprocentują w przyszłości. Ważne, żebyśmy trzymali rękę na pulsie i nie ulegali pokusie zwiększania czasu pomiędzy końcem Sprintu i planowaniem kolejnego.



KTO?

W przeglądzie sprintu bierze zawsze udział cały Zespół Scrumowy. Deweloperzy i Właściciel Produktu są odpowiedzialni odpowiednio za pokazanie swej pracy i wynikającego z niej Przyrostu oraz za omówienie Product Backlogu, natomiast Scrum Master czuwa nad przebiegiem spotkania i upewnia się, że jego cel został osiągnięty. Co za tym idzie, jeśli nasz koniec sprintu przypada na jakieś święto lub zwiększoną liczbę urlopów, starajmy się dopasować termin Przeglądu tak, by mogła w nim wziąć udział jak największa liczba członków zespołu. Jeśli oznacza to dzień wcześniej niż przypada koniec sprintu, pamiętajmy o wskazówkach opisanych powyżej. Oczywiście, bez większości zespołu spotkanie nie ma większego sensu, natomiast prawdziwa magia dzieje się dopiero wtedy, gdy na przegląd dodatkowo przychodzą interesariusze, klienci, inne zespoły współpracujące, czy nawet wysocy rangą dyrektorzy, bądź członkowie zarządu. Dzięki tym osobom Zespół Scrumowy dostaje ogromną dawkę informacji zwrotnych na temat swojego produktu, to te osoby zadają trudne i ciekawe pytania, które mogą pobudzić kreatywność zespołu, i przy udziale tych osób Review zamienia się w jeszcze bardziej wartościowe spotkanie. Gorąco zachęcam zespoły, by zawsze zastanawiały się, kogo warto zaprosić na przegląd, komu poza Właścicielem Produktu należy zaprezentować dokonania, i dbały, by na spotkaniu był ktoś jeszcze poza Zespołem Scrumowym.

JAK?

Scrum Guide dosyć wyraźnie wskazuje, kto odpowiada za poszczególne części spotkania, by przeprowadzić je we właściwy sposób. Zespół Deweloperski opowiada o swojej pracy, czyli prezentuje, co udało mu się wykonać, jakie napotkał problemy w trakcie Sprintu i jak sobie z nimi poradził. Właściciel Produktu natomiast wprowadza uczestników spotkania, wyjaśniając, które elementy Backlogu Sprintu zostały ukończone, a które niestety nie, i omawia dalsze losy produktu uaktualniając odpowiednio Backlog Produktu. Podział prac zatem jest prosty, natomiast zdarza się, że zespoły o tym zapominają i dopytują, kto powinien prowadzić spotkanie. Pamiętajmy zatem, że ten podział z czegoś wynika, że stoi za nim jakiś zamysł autorów. Jaki? Ano taki, że skoro to Zespół Deweloperski pracował nad produktem, to on najlepiej wie, co i jak wykonał, więc powinien mieć możliwość pochwalić się swoimi dokonaniami i wyjaśnić, co stoi za wybranymi rozwiązaniami. Natomiast Właściciel Produktu odpowiada za Backlog Produktu, więc to on będzie miał największą wiedzę i tzw. “big picture” na temat dalszych losów produktu i będzie w stanie podjąć dyskusję w tym temacie z gośćmi na spotkaniu. Czasami zdarza się, że Właściciel Produktu prezentuje wszystko i prowadzi całe spotkanie, ale wówczas znika nam element zaangażowania zespołu, a ponadto zmienia nam się relacja pomiędzy PO i zespołem. PO zaczyna mówić jak zespół “zrobiliśmy, wykonaliśmy”, a zapomina, że jego rolą jest jednak odebrać od zespołu wykonaną pracę. Dbajmy zatem o zrozumienie odpowiedzialności każdej z ról biorących udział w przeglądzie.

PO CO?

Fundamentalnymi zasadami Scruma i zwinnych metod pracy są inspekcja i adaptacja. Przegląd Sprintu jest spotkaniem, które służy właśnie tym dwóm zasadom. Dokonujemy inspekcji Przyrostu (wykonanej pracy), sprawdzamy, co udało nam się wykonać,  weryfikujemy, gdzie jesteśmy z wytwarzaniem produktu, i korzystamy z informacji zwrotnej od interesariuszy i klientów, ponieważ chcemy jak najszybciej dopasować swoje następne działania do rzeczywistości. Wspólnie, całym Zespołem Scrumowym zastanawiamy się, jakie kolejne elementy powinny zostać wykonane w następnym Sprincie, by ponownie dostarczyć najwyższą wartość, sprawdzamy, jak zmienił się międzyczasie rynek i jak powinniśmy w związku z tym zareagować. Jeśli jest taka potrzeba aktualizujemy plany wydań, budżet i wymogi dotyczące produktu. Wszystko po to, byśmy mieli przekonanie, że co Sprint uzyskujemy dzięki naszej pracy to, co najlepsze dla rozwoju produktu.

KU PAMIĘCI…

Na pewno zdarzą się wam nieraz Sprinty, w których nie wykonacie zaplanowanych prac, w których z jakichś względów poniesiecie porażkę. Agile i Scrum nie piętnują osób, którym przytrafi się błąd. Najważniejsze, żebyście zawsze wyciągali z każdej porażki lekcję i zastanowili się, co możecie w kolejnym Sprincie zrobić inaczej, lepiej, by zminimalizować jeszcze bardziej ryzyko niewykonania zadań. Ale o tym następnym razem, gdy zajmiemy się ostatnim ze spotkań scrumowych – Retrospektywą…

Posłuchaj nagrania podcastu Porządny Agile – Porządny Przegląd Sprintu

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