Sprint Review czyli Przegląd Sprintu

Tym razem chcemy poruszyć temat Sprint Review. W wielu organizacjach w większości sytuacji jest to nie do końca zrozumiałe wydarzenie Scrum. Bardzo dużo osób, szczególnie na początku drogi ze Scrum, sprowadza Sprint Review wyłącznie do demonstracji przyrostu wykonanego przez Developerów, co jest błędem. W rzeczywistości jest to bardzo ważne wydarzenie, które wykorzystuje trzy filary Scrum.  

Czym jest Sprint Review?

Sprint Review to wydarzenie, w którym wykonuje się sprawdzenie przyrostu produktu. Przyrost to nic innego jak elementy Sprint Backlogu ukończone w trakcie sprintu przez Developerów. Wiecie już, że każde wydarzenie w Scrum posiada swój timebox. W przypadku Sprint Review wynosi on 4 godziny dla czterotygodniowego Sprintu (dla krótszych Sprintów czas Review jest proporcjonalnie mniejszy). Sprint Review jest to nieformalne spotkanie robocze, gdzie wszyscy uczestnicy współpracują w celu dokonania inspekcji oraz adaptacji.  

Uczestnicy Sprint Review 

Uczestnikami Sprint Review jest nie tylko Zespół Scrum, a również np. przedstawiciele biznesu, management oraz klienci, czyli osoby dla których budujemy dany produkt. Dzięki poznaniu opinii pochodzących ze strony interesariuszy, Zespół Scrum ma możliwość uzyskania informacji o wartości przyrostu produktu podlegającego inspekcji.

Przegląd Sprintu to miejsce, gdzie Developerzy mają możliwość przekazania informacji co się wydarzyło podczas Sprintu, co mogło mieć pozytywny lub negatywny wpływ na osiągnięcie Sprint Goal oraz na budowany przyrost. 

Product Owner pełni ważną rolę w trakcie Sprint Review. Jest gospodarzem i narratorem podczas wydarzenia, dba o uczestnictwo odpowiednich osób w procesie inspekcji i adaptacji przyrostu.  

Rolą Scrum Mastera podczas Sprint Review jest edukacja Zespołu Scrum w zakresie prawidłowego przebiegu wydarzenia z zachowaniem wszystkich jego elementów. Scrum Master dba również o utrzymanie odpowiedniego timeboxu oraz o przyjazną atmosferę podczas Sprint Review – stara się rozładowywać potencjalne konflikty lub burzliwe dyskusje. 

Najczęstsze anty-wzorce Sprint Review 

Przegląd Sprintu to nie tylko demo. 

Tak ja już wspomnieliśmy na początku tego posta, bardzo często zdarza się, że Sprint Review jest traktowane jako demo danego przyrostu. Jest to niepoprawne podejście, ponieważ nie jest dokonywana pełna inspekcja i adaptacja, a uwaga skupia się wyłącznie na tym, co udało się Developerom osiągnąć podczas Sprintu. 

Na Sprint Review nie ma przedstawicieli biznesowych produktu. 

W tym przypadku nie ma możliwości zebrania feedbacku, a co za tym idzie Zespół Scrum może nie mieć pewności, czy część danego produktu przynosi wartość, czy nie. Przez takie podejście nie mamy też możliwości adaptacji naszych przyszłych planów odnośnie produktu. Dodatkowo Sprint Review przeprowadzone w gronie interesariuszy daje doskonałą okazję na uzyskanie informacji dotyczących np. sytuacji na rynku, zadowolenia klientów czy planowanych akcji po stronie biznesu współtowarzyszących rozwojowi produktu, np. kampanie marketingowe.  

Scrum Master lub Product Owner przejmuje w całości Sprint Review. 

W tej sytuacji Developerzy występują jako publiczność (lub paprotki 🙂 ) tego wydarzenia, a nie osoby, które opowiadają o Sprincie oraz jego przyroście.

Brak Sprint Review po każdym Sprincie. 

W momencie, kiedy Zespół Scrum nie posiada Sprint Review nie otrzymuje też feedbacku, a co za tym idzie nie jest wykonana inspekcja i adaptacja.

Sprint Goal pomijany podczas Sprint Review

Brak stworzonego Celu Sprintu powoduje utratę informacji na temat przyczyny wykonania przyrostu produktu. Dodatkowo Sprint Goal wskazuje na zgodność kierunku planowanych Sprintów z Celem Produktu, jak również jego wizją.

To jak powinien wyglądać Przegląd Sprintu?

Poniżej w punktach przedstawiamy na co zwrócić uwagę podczas Sprint Review, aby przynosiło pozytywną wartość dla interesariuszy jak i samego Zespołu Scrum:

  1. Product Owner zaprasza osoby z biznesu, które mogą przekazać feedback
  2. Product Owner rozpoczyna spotkanie oraz “ustawia scenę”, czyli tłumaczy co i jak podczas spotkania zostanie wykonane
  3. Zespół Scrum komunikuje, czy cel sprintu został wykonany
  4. Developerzy przekazują informacje co się udało zrobić oraz z czym mieli problemy
  5. Developerzy pokazują oraz omawiają działający przyrostu – inspekcja przyrostu (Uwaga: w przypadku kiedy Developerzy nie mają co pokazać bo na przykład nie udało im się zbudować przyrostu, to w sposób jasny i transparentny o tym informują)
  6. Osoby biznesowe przekazują swój feedback na temat produktu i dzielą się informacjami napływającymi z otoczenia produktu
  7. Zespół Scrum wraz z biznesem dokonuje adaptacji Backlogu Product w celu osiągnięcia maksymalizacji wartości i odzwierciedlenia potencjalnych zmian priorytetów, mogących mieć odzwierciedlenie w planowaniu następnego Sprintu
  8. Scrum Master zajmuje się facylitacją całego wydarzenia, jak również dba o utrzymanie odpowiedniego timeboxu

Podsumowanie

Sprint Review lub Przegląd Sprintu jest bardzo ważnym wydarzeniem Scrum. Dzięki niemu zarówno Zespół Scrum, jak i strona biznesowa wiedzą, czy budowany produkt przynosi spodziewaną wartość. Dodatkowo można zmienić/zaktualizować dalsze plany budowy następnych części produktu, dzięki czemu zwiększamy poziom zwinności biznesowej, a co za tym idzie produkt, który rozwijamy stanie się bardziej konkurencyjny na rynku. Pamiętajmy jednak o tym, aby unikać anty-wzorców, przez które wiele zespołów może nie widzieć sensu uczestnictwa w tym wydarzeniu Scrum.

O tym, jak wygląda Sprint Review oraz inne wydarzenia Scrum dowiesz się więcej na naszych szkoleniach.