Jak przeprowadzić Przegląd Sprintu, czyli Sprint Review

W mojej serii praktycznych poradników o Scrum, jako pierwszy na tapetę wzięłam Product Backlog i wskazówki dotyczące jego efektywnej pielęgnacji. Następny w kolejności materiał postanowiłam, że będzie odpowiadał na pytanie JAK przeprowadzić Przegląd Sprintu (z ang. Sprint Review). Podobnie jak często Product Owner doprowadza swój Backlog do stanu tzw. ‘chaosu pod kontrolą’, tak również zespoły zwinne zapominają o roli Przeglądu Sprintu. Powinien być on zorganizowany tuż po zakończeniu iteracji przez zespół dla interesariuszy.

W dużym skrócie, Przegląd Sprintu to spotkanie podczas którego dokonujemy tzw. “inspekcji przyrostu”, czyli pracy wykonanej w Sprincie. Weryfikujemy i pokazujemy innym gdzie jesteśmy, jaki jest obecny stan naszego produktu, jak udało nam się rozwiązać napotkane problemy w trakcie realizacji zadań i jakie rozwiązania stworzyliśmy.

Ideą spotkania jest to, aby to zespół scrumowy przedstawił interesariuszom zaproszonym na spotkanie, co udało się zrealizować. Product Owner, odnosząc się do Backlogu, zbiera feedback od uczestników, inicjuje dyskusje dotyczące zmian czy kontynuacji prac, dzięki czemu cały zespół jest zaangażowany w dostarczanie wartości biznesowej, która stoi za rozwiązaniami wytwarzanymi przez zespół. Na podstawie informacji zwrotnej od interesariuszy, zespół aktualizuje Backlog Produktu.

Co na temat Przeglądu Sprintu mówi Scrum Guide?

1. Przegląd odbywa się pod koniec Sprintu – w spotkaniu bierze udział zespół scrumowy oraz interesariusze zaproszeni przez Product Ownera.
2. Celem tego spotkania jest zoptymalizowanie wartości z przyszłych działań zespołu scrumowego – właśnie temu służy zebranie feedbacku od interesariuszy i aktualizacja Backlogu.
3. Maksymalny czas trwania to 4 godziny dla Sprintu trwającego 1 miesiąc. Dla krótszych iteracji, spotkanie może być proporcjonalnie krótsze.
4. Product Owner prezentuje zadania w Backlogu, które zostały ukończone, oraz omawia te, których dokończyć się nie udało.
5. Zespół mówi o tym, co poszło w Sprincie dobrze, co było problematyczne, jak główne problemy zostały przez zespół rozwiązane. Odpowiada także na wszystkie pytania interesariuszy dotyczące nowego “przyrostu produktu” – czyli nowej wersji produktu, powstałej w ramach Sprintu.
6. Wszyscy zgromadzeni dyskutują na temat tego, co powinno być realizowane jako następne. Te dane Product Owner wykorzystuje w priorytetyzacji i mają one wpływ na kolejne Planowanie Sprintu.
7. Wszyscy zgromadzeni przeglądają harmonogram, budżet, zasoby na kolejne iteracje i wydania produktu.
   

   The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

   Źródło: Scrum Guide

Sprint Review w praktyce – jak przygotować i przeprowadzić to spotkanie?

W zależności od tego jak dojrzały jest nasz biznes, czy projekt, po zakończeniu iteracji powinniśmy mieć gotową część działającego produktu lub nową wersję produktu. Możemy ją wówczas zaprezentować jako „demo” wszystkim zainteresowanym stronom. Pokazać co dokładnie zrobiliśmy, jak produkt się zmienił, jak obecnie działa.

Podczas prezentacji, Product Owner przysłuchuje się uwagom zainteresowanych, sam też przygląda się dokładnie produktowi. Sprawdza, czy zaprezentowana jego część odpowiada założeniom ustalonym na początku Sprintu i czy wymaga dalszych optymalizacji, zbiera opinie interesariuszy. Uzupełnia Product Backlog o nowe funkcjonalności, które wyklarowały się w czasie iteracji i prezentacji demo oraz o ewentualne błędy które należy poprawić.

W praktyce często Przegląd Sprintu prowadzi Product Owner i to on przedstawia to, co udało się zrealizować całemu zespołowi. Wtedy jednak znika element zaangażowania zespołu. Scrum Guide rekomenduje, aby to zespół w trakcie Przeglądu zademonstrował to, co zostało zrealizowane i opowiedział o tym, jakie wyzwania napotkał w trakcie Sprintu. Aby ułatwić każdorazowe przygotowanie do spotkania można zaopatrzyć zespół w szablon prezentacji na Sprint Review. W szablonie można odzwierciedlić agendę (propozycję znajdziesz poniżej) oraz oznaczyć, za które slajdy odpowiada zespół, za które Product Owner.

Na co zwracać uwagę przeprowadzając Przegląd Sprintu

1. Wstaw sam(-a) lub poproś zespół o wstawienie spotkania do kalendarza. Niech przegląd będzie zawsze o tym samym czasie, w tym samym dniu, aby zespół pamiętał, że się odbywa i zaplanował prace związane z przygotowaniem się do spotkania.

2. Zastanów się, kto jeszcze poza zespołem scrumowym powinien uczestniczyć w spotkaniu. Kto jest zainteresowany nowym przyrostem i może Wam przekazać zasadny feedback dla rozwiązań, które w nim powstały. W zależności od sytuacji, zaproś tych interesariuszy na stałe na Wasze spotkanie lub dodawaj na kolejne spotkania tych, którzy są kluczowi.

3. Każdy Przegląd Sprintu powinien mieć zaplanowaną agendę. Upewnij się, że zespół ma plan, co w jakiej kolejności pokazuje i każdy jest tego świadomy i przygotowany. Dodaj agendę do spotkania w kalendarzu, aby również interesariusze wiedzieli z wyprzedzeniem, czego będzie dotyczyło.

Przykładowa agenda spotkania Sprint Review

1. Cele Sprintu – jakie były i czy udało się je zrealizować.
2. Wyświetlenie, analiza i omówienie Wykresu Spalania (z ang. Burndown Chart) i Raportu z testów. Omówienie głównych problemów w trakcie Sprintu (np. wrzutek od interesariuszy i ich wpływu na cele) oraz krótkie podsumowanie tematów związanych z Jakością.
3. Prezentacja przyrostu (zespół pokazuje co zmieniło się w produkcie).
   Zebranie feedbacku przez Product Ownera w celu aktualizacji Product Backlogu.
4. Backlog Produktu – omówienie zadań, które zostały zrealizowane oraz zadań zaplanowanych jako następne w kolejności do realizacja. Dyskusja na temat priorytetów z zespołem i interesariuszami.
5. Dług technologiczny – na jakie “skróty” trzeba było pójść i będzie wymagało optymalizacji w kolejnych etapach, lub co technologicznie udało się zoptymalizować w Sprincie.
6. Weryfikacja harmonogramu, budżetu, zasobów i ryzyk (jeżeli firma pracuje projektowo i jest taka potrzeba).

Podsumowanie

Przegląd Sprintu to ważne spotkanie, które nie bez przyczyny jest elementem Scruma. Zespół upewnia się dzięki niemu, że to co zrobił ma sens, dlatego bardzo ważne jest aby cały zespół w tym spotkaniu uczestniczył.

Sprint Review wspiera komunikację w zespole i firmie, jest możliwością dla Product Ownera do zbierania feedbacku od głównych interesariuszy, a także ważnym elementem procesu Pielęgnacji Backlogu. Product Owner utrzymuje porządek w Product Backlogu i historyjkach, również po to, aby były łatwe do zrozumienia przez interesariuszy.

Poprzedni artykuł napisałam, dlatego że miałam wyrzuty sumienia dotyczące stanu Backlogu Produktu. Pisząc go zorientowałam się, że jednym z źródeł moich problemów backlogowych jest właśnie brak poprawnie przeprowadzonego spotkania Sprint Review. W SentiOne dotychczas organizowaliśmy jedyne “demo” dla interesariuszy, na którym razem z zespołem pokazywaliśmy efekty prac w kilku poprzednich iteracjach. Po każdymprincie na bieżąco (lecz jedynie między sobą w zespole) weryfikowaliśmy przyrost tuż przed retrospektywą. Nie jest to “zgodne” ze Scrum Guidem, a efektami tej niezgodności są: nieuporządkowany Backlog, brak zrozumienia interesariuszy na temat tego co dzieje się w Sprincie, brak wpływu interesariuszy na decyzje projektowe i dotyczące rozwoju produktu.