Sprint się kończy, zespół pokazuje efekty pracy, a klient patrzy na ekran i pyta: "to tyle przez dwa tygodnie?". Problem rzadko leży w tempie pracy zespołu - najczęściej leży w tym, jak zorganizowane jest spotkanie podsumowujące. Dobrze przeprowadzony Sprint Review zamienia to samo demo w moment, który buduje zaufanie zamiast je podważać.
Wiele zespołów traktuje Sprint Review jako formalność do odhaczenia albo myli je z retrospektywą. To błąd - każde z tych spotkań ma inny cel i inną publiczność, a pomylenie ich prowadzi do spotkań, które nie dają żadnej z korzyści.
W tym artykule pokażę, czym jest Sprint Review, jak się różni od retrospektywy, kto powinien w nim uczestniczyć i jak przygotować spotkanie, które faktycznie daje wartość zespołowi i interesariuszom.
Czym jest Sprint Review i jaki ma cel
Sprint Review to spotkanie kończące sprint, na którym zespół prezentuje ukończoną pracę interesariuszom i zbiera od nich informację zwrotną. Celem nie jest pokazanie, ile godzin zespół przepracował, tylko sprawdzenie, czy to, co powstało, faktycznie rozwiązuje problem odbiorcy.
To spotkanie ma charakter roboczy, nie prezentacyjny w stylu korporacyjnej konferencji. Dobre Sprint Review wygląda bardziej jak rozmowa i wspólne testowanie funkcji niż jak slajdy z wynikami.
Sprint Review vs Retrospektywa - różnice
To dwa najczęściej mylone spotkania w Scrumie. Sprint Review odpowiada na pytanie "co zrobiliśmy i czy to działa dla odbiorcy", a retrospektywa odpowiada na pytanie "jak nam się pracowało i co poprawić w procesie zespołu".
Sprint Review skupia się na produkcie i angażuje interesariuszy z zewnątrz zespołu - klienta, właściciela produktu, czasem zarząd. Retrospektywa dotyczy wyłącznie procesu pracy zespołu deweloperskiego i odbywa się w gronie zamkniętym, bez osób z zewnątrz.
Praktyczna zasada: jeśli na spotkaniu pojawia się zdanie "a może zmienimy sposób, w jaki się komunikujemy na dailly", to temat na retrospektywę, nie na Sprint Review. Więcej o samych codziennych spotkaniach zespołu przeczytasz w artykule o Daily Scrum.
Jak długo powinno trwać Sprint Review
Długość spotkania warto dopasować do długości sprintu, nie do liczby zadań do pokazania. Dla dwutygodniowego sprintu sprawdza się spotkanie trwające od trzydziestu do sześćdziesięciu minut - dłuższe demo zaczyna męczyć uczestników i obniża jakość zbieranego feedbacku.
Jeśli lista rzeczy do pokazania regularnie nie mieści się w tym czasie, to zwykle sygnał, że sprint obejmował zbyt wiele niepowiązanych ze sobą tematów. Lepiej pokazać mniej elementów, ale każdemu poświęcić czas na pytania i dyskusję, niż przelecieć przez dziesięć funkcji w tempie uniemożliwiającym jakąkolwiek reakcję.
Kto powinien uczestniczyć w Sprint Review
Podstawowy skład to cały zespół deweloperski, Product Owner i Scrum Master, jeśli taka rola funkcjonuje w zespole. To minimum, które pozwala ocenić, czy praca została ukończona zgodnie z ustaleniami.
Prawdziwą wartość Sprint Review daje jednak obecność interesariuszy z zewnątrz - klienta, przedstawiciela działu sprzedaży, użytkownika końcowego. To oni najlepiej ocenią, czy nowa funkcja faktycznie rozwiązuje ich problem, a nie tylko spełnia wymagania zapisane na początku sprintu.
Przykład: software house tworzący system do zarządzania magazynem zaprasza na Sprint Review osobę odpowiedzialną za magazyn u klienta. Ta osoba w pięć minut zauważa, że nowy formularz przyjęcia towaru wymaga zbyt wielu kliknięć - informacja, której zespół deweloperski sam by nie wychwycił.
Jak przygotować się do Sprint Review
Przygotowanie zaczyna się na długo przed samym spotkaniem - dobre demo nie powstaje w ostatniej chwili.
Co pokazać, a czego nie pokazywać
Pokazuj tylko to, co spełnia Definition of Done ustalone przez zespół. Prezentowanie niedokończonej funkcji jako gotowej rodzi fałszywe oczekiwania i podważa zaufanie przy kolejnych sprintach, gdy okaże się, że "gotowe" jednak wymagało jeszcze dwóch tygodni poprawek.
Nie pokazuj kodu ani szczegółów technicznych, chyba że odbiorcy są techniczni. Interesariusza biznesowego interesuje efekt działania funkcji z perspektywy użytkownika, a nie architektura rozwiązania.
Rola Product Ownera
Product Owner odpowiada za ramy spotkania - przypomina cel sprintu, wskazuje, które elementy backlogu zostały zrealizowane, a które przesunięto i dlaczego. To on prowadzi rozmowę o tym, jak wyniki sprintu wpływają na dalsze priorytety produktu, w tym na aktualność roadmapy projektu.
Ważne jest też, żeby Product Owner nie tłumaczył się z niezrealizowanych elementów jak z porażki. Przesunięcie zadania do kolejnego sprintu to normalna część pracy, o ile towarzyszy mu jasne wyjaśnienie przyczyny - zmiany priorytetów, nieprzewidzianej złożoności albo zależności od innego zespołu.
Przebieg efektywnego Sprint Review krok po kroku
Spotkanie warto otworzyć krótkim przypomnieniem celu sprintu - jednym zdaniem, bez wracania do całej historii projektu. Następnie każdy element pracy jest prezentowany osobno, najlepiej przez osobę, która go faktycznie wykonała, a nie wyłącznie przez Product Ownera.
Po każdej prezentacji warto zrobić krótką przerwę na pytania i reakcje, zamiast czekać z dyskusją do końca spotkania. Reakcje na bieżąco są bardziej szczere i konkretne niż komentarze zebrane po obejrzeniu całości.
Na koniec spotkania Product Owner podsumowuje zebrany feedback i zaznacza, które uwagi trafią do backlogu jako nowe zadania, a które wymagają dalszej analizy przed podjęciem decyzji.
Najczęstsze błędy podczas Sprint Review
Zamiana spotkania w prezentację slajdów zamiast pokazania działającego produktu. Interesariusze pamiętają to, co widzieli na żywo, a nie opis w punktach.
Pokazywanie funkcji, które nie są w pełni ukończone, z zastrzeżeniem "to jeszcze wymaga poprawek". Takie demo nie daje rzetelnej informacji o postępie i psuje zaufanie do statusów raportowanych przez zespół.
Brak przygotowania środowiska demo, przez co połowa spotkania schodzi na naprawianie błędów konfiguracji zamiast na rozmowę o produkcie.
Pomijanie zaproszenia interesariuszy zewnętrznych i traktowanie Sprint Review jako wewnętrznego spotkania zespołu - wtedy spotkanie traci swój główny cel, czyli zebranie zewnętrznej informacji zwrotnej.
Przeciąganie spotkania bez struktury, gdy każda prezentowana funkcja wywołuje długą dyskusję odbiegającą od tematu. Warto z góry ustalić, że pogłębione rozmowy o pojedynczym zagadnieniu przenoszą się na osobne spotkanie robocze, a Sprint Review pozostaje przeglądem całości.
Jak zbierać feedback od interesariuszy
Feedback zebrany podczas Sprint Review jest wartościowy tylko wtedy, gdy zostanie gdzieś zapisany i faktycznie trafi do dalszej pracy zespołu, a nie zniknie razem z notatkami ze spotkania. Warto ustalić jedno miejsce, w którym takie uwagi lądują od razu podczas spotkania.
Pomocne jest rozróżnienie trzech typów feedbacku: drobne poprawki, które można dodać jako pojedyncze zadania do backlogu, większe zmiany wymagające osobnej analizy przed priorytetyzacją, oraz uwagi ogólne dotyczące kierunku produktu, które powinny wpłynąć na przyszłą roadmapę, a nie na najbliższy sprint.
Dobrą praktyką jest też krótkie podsumowanie wysłane po spotkaniu do wszystkich uczestników - lista tego, co pokazano, jakie decyzje zapadły i co dzieje się dalej z każdą zgłoszoną uwagą. Więcej o zasadach zapisywania takich ustaleń znajdziesz w artykule o efektywnych spotkaniach zespołowych.
Zdarza się, że feedback od jednego interesariusza jest sprzeczny z feedbackiem innego - na przykład dział sprzedaży chce więcej pól w formularzu, a użytkownicy końcowi skarżą się, że formularz jest już za długi. W takich sytuacjach Sprint Review nie jest miejscem na podjęcie ostatecznej decyzji. Rolą Product Ownera jest zebranie obu perspektyw i rozstrzygnięcie sprzeczności później, poza samym spotkaniem, na podstawie danych albo priorytetów biznesowych.
Sprint Review w Taskello
W Taskello Sprint Review można oprzeć na tablicy sprintu - kolumna "Gotowe" pokazuje dokładnie te zadania, które zespół zaprezentuje na spotkaniu, a każde zadanie ma swój opis i historię zmian, do których można się odwołać podczas demo.
Uwagi zebrane od interesariuszy da się od razu dodać jako nowe zadania w projekcie, z odniesieniem do zadania źródłowego, którego dotyczyły. Dzięki temu żaden komentarz z Sprint Review nie ginie w notatkach ze spotkania, tylko trafia bezpośrednio tam, gdzie zespół planuje kolejne prace - obok bieżącego planowania sprintu. Jeśli zespół dopiero wdraża Scrum, warto zacząć od podstaw opisanych w artykule Scrum - kompletny przewodnik dla początkujących.
Sprint Review nie musi być stresującym pokazem dla zarządu. Dobrze przygotowane, skupione na działającym produkcie i szczerej rozmowie z odbiorcami, staje się jednym z najbardziej wartościowych spotkań w całym cyklu sprintu - bo to właśnie tam zespół dowiaduje się, czy pracuje nad właściwymi rzeczami.