Sprint Review czyli Przegląd Sprintu

Widzieliśmy wiele różnych spotkań tego typu. Pomysłów na Sprint Review jest nieskończenie wiele. Jedne są organizowane jako warsztaty, inne prowadzone są w formie, która usypia potencjalnych słuchaczy, gdzieś pojawia się także “demo”. Czym właściwie jest Sprint Review i jaką rolę pełni w metodyce Scrum?

 

Sprint Review

Przegląd Sprintu (ang. Sprint Review) to nic innego jak spotkanie Scrum mające na celu przegląd inkrementu oraz, jeśli zajdzie taka potrzeba, dostosowania Backlogu Produktu. Tajemniczo brzmiący “przegląd inkrementu” to nic innego niż analiza tego, co zostało w ostatnim Sprincie ukończone. Mówiąc o dostosowaniu Backlogu Produktu myślimy o wprowadzeniu w nim zmian, w oparciu o to, co zostało ukończone.

Mówiąc inaczej, Sprint Review to aktualizacja Backlogu Produktu w związku z tym, co zostało zrealizowane w ostatnim Sprincie. Oczywiście w tym celu konieczne jest wyjaśnienie, które wymagania zostały ukończone, co poszło dobrze w trakcie Sprintu i jak rozwiązano ewentualne problemy. Przydaje się prezentacja pracy (jeśli jest co pokazać) i omówienie przyrostu. Zdecydowanie warto pochylić się nad kolejnymi krokami, omówić backlog i uwzględnić zmiany w rynku, konkurencji, czasie, budżetach, itd.

Sprint Review, podobnie jak inne wydarzenia w Scrum posiada swój timebox. W przypadku Przeglądu Sprintu są to cztery godziny dla miesięcznego Sprintu i proporcjonalnie mniej dla krótszych Sprintów. Jest to oczywiście czas maksymalny i nikt nie będzie siedział patrząc na zegarek, gdy już wszystko zostanie omówione. Ale o tym wszyscy powinniśmy doskonale wiedzieć.

Taki suchy opis nie oddaje jednak ani istoty, ani prawdziwej natury tego spotkania, które wspiera podejście inspect and adapt. Te filary Scruma co prawda są widoczne w każdym wydarzeniu, roli i artefakcie, ale nie zawsze mamy tak jasno na dłoni pokazane “kto, co i dlaczego”.

 

Uczestnicy Przeglądu Sprintu

Uczestnikami Przeglądy Sprintu są przede wszystkim interesariusze. I chociaż nie jest to najlepsze słowo, to doskonale określa “osoby zainteresowane naszym projektem”. Spotykają się oni z nami, czyli z Zespołem Scrumowym po to, aby wspólnie dokonać opisanych powyżej czynności. Niezwykle ważne jest, abyśmy zaprosili właściwe osoby. Takie, które są bezpośrednio zainteresowane produktem naszych prac, a może nawet mają “skin in the game“. To od nich powinniśmy uzyskać potwierdzenie dalszego kierunku, w którym zmierzamy.

Widzieliśmy Przeglądy Sprintu, gdzie uczestnikami byli tylko członkowie Zespołu Scrumowego albo, w wersji ekstremalnej, jedynie Zespołu Deweloperskiego. Powoduje to, że tracimy możliwość poznania wizji i potrzeb klienta, możliwość wsłuchania się w sposób w jaki dokonuje on przeglądu inkrementu czy nawiązania z nim konstruktywnej dyskusji. Te aspekty są bezcenne.

Z drugiej strony, trzeba pamiętać, że to Product Owner należy do osób najbardziej zainteresowanych tematem postępu prac. Na podstawie tego, co dowie się na spotkaniu Sprint Review zaktualizuje on krótko- i długoterminowe plany i prognozy. Prawdopodobnie też przyjrzy się velocity poszczególnych zespołów, co pozwoli na lepsze podzielenie wymagań na te, które trzeba zrealizować “teraz-zaraz” i te, które mogą poczekać.

Co nie znaczy, że jest to jedyny, ani nawet główny, produkt spotkania o nazwie Przegląd Sprintu.

 

Po co robimy Sprint Review?

Sprint Review nie powinno być rozumiane jako demo, a więc nie powinniśmy iść na nie z przeświadczeniem, że oto zaraz obejrzymy prezentację działania systemu. Nie jest to też spotkanie statusowe. Niestety, są to najczęstsze pomyłki dotyczące Przeglądu Sprintu i wiele razy pierwszym krokiem do przywrócenia scrumowej normalności jest zmiana nazwy z “demo” na “review”. Bowiem sens tego wydarzenia jest zupełnie inny.

Największą wartością płynącą z Przeglądu Sprintu jest uzyskanie informacji zwrotnej, a więc popolularnego “fidbeku” (ang. feedback). Będzie to ocena, a w niektórych przypadkach szczegółowa informacja o tym, czy sposób przekształcenia wymagań na inkrement jest zgodny z wizją klienta. Będzie to również weryfikacja tego, jak bardzo Product Owner i Zespół Deweloperski nadają na tych samych falach, jeżeli chodzi o zrozumienie potrzeb klienta.

“uczestnicy spotkania wspólnie rozważają, co mogłoby być wykonane w następnej kolejności, aby zoptymalizować wartość” – Scrum Guide

Kapitalne znaczenie w naszej ocenia ma słowo “wspólnie”. Oznacza ono, że każdy uczestnik spotkania ma głos w sprawie tego, co możemy zrobić aby zmaksymalizować wartość naszego produktu. Mowa tu zarówno o interesariuszach, jak i członkach Scrum Team. Przekłada się to na wspólne rozumienie celu naszej pracy w ujęciu Big Picture. Zyskujemy całościowe spojrzenie na projektowany system.

Wspomniałem na początku o zarządzaniu Backlogiem Produktu. Ten element spotkania ma za zadanie potwierdzenie aktualności poszczególnych wymagań lub zmianę priorytetów już istniejących. Jeśli zajdzie potrzeba, do listy wymagań mogą zostać dopisane nowe.

W ramach Sprint Review wykorzystujemy to, że mamy możliwość zmiany kierunku nawet na każdym etapie trwania projektu. Wykorzystujemy to, że jesteśmy w stanie szybko odpowiedzieć na działania konkurentów lub zmiany na rynku. Jednym słowem – wykorzystujemy obecność wszystkich zainteresowanych, aby osiągnąć sukces.

 

Forma Przeglądu Sprintu

Na początku wspomniałem o tym, że widzieliśmy wiele dobrych i złych przykładów na organizację Przeglądu Sprintu. Jedne były udane, inne nie. Nie możemy jednak jednoznacznie wskazać tych sposobów, które warto wykorzystać. Trudno wskazać tu jakiekolwiek “dobre praktyki”, nie mówiąc już o wybieraniu “najlepszych”.

To co zadziało w jednej organizacji nie musi się sprawdzić w innej. W każdym miejscy pracują inni ludzie i w każdym miejscu będą inne potrzeby. Jedno jest pewne. Forma Sprint Review powinna maksymalizować korzyści z niego wynikające. Są one na tyle istotne, że musimy być absolutnie pewni, że sposób naszego Przeglądu jest odpowiedni.

Scrum Guide wymienia osiem punktów do zrealizowania w ramach Sprint Review. Ten post, miejmy nadzieję, przybliża ideę i cel tego spotkania. Na tej podstawie można zrobić retrospekcję Przeglądu Sprintu i zweryfikować, czy działamy we właściwy sposób. A jeżeli nie, to usprawnienia możemy wprowadzić już w kolejnym Sprincie.

 

Tematykę Sprint Review i innych scrumowych wydarzeń poruszamy w szczegółach na naszych szkoleniach Scrum i Agile.

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: