Sprint Review jest jednym z 5 wydarzeń scrumowych, które umożliwiają pracę w oparciu o empiryzm. Poprzez praktykowanie przejrzystości, inspekcji i adaptacji Zespół ma możliwość nie tylko zebrania opinii Interesariuszy o dostarczonym Przyroście, ale również prowadzenia dyskusji wspierających decyzje o dalszych etapach rozwoju Produktu.
O Sprint Review słów parę
Sprint Review jest wydarzeniem, które jest kluczowe w empirycznym procesie tworzenia Produktu. Jego celem jest wspólna z Interesariuszami inspekcja rezultatów pracy wykonanej w Sprincie, w odniesieniu do Celu Produktu [1, 2]. Biorąc pod uwagę wyniki inspekcji, adaptujemy plan dalszego rozwoju Produktu.
Jednak nie tylko Przyrost powinien podlegać inspekcji w trakcie spotkania (wykonanie tzw. demo). Spotkanie to daje, często niewykorzystywane przez Zespoły, możliwości rozmowy o tym jak przebiegała praca w Sprincie, jak aktualnie wygląda Product Backlog i Roadmapa, czy wymagają one aktualizacji, oraz czy zmiany rynkowe wpływają na planowany rozwój Produktu.
Aby wydarzenie miało sens, powinno odbywać się z poszanowaniem filaru przejrzystości. Oznacza to, że pokazujemy wszystko takie jakie jest, niczego nie ukrywamy i staramy się uzyskać wspólne z Interesariuszami rozumienie obecnej sytuacji.
Wydarzenie to może trwać maksymalnie 4 godziny dla miesięcznego Sprintu. Dla krótszych Sprintów trwa ono zazwyczaj krócej.
Kto powinien pojawiać się na Sprint Review?
W spotkaniu uczestniczy cały Zespół Scrumowy, czyli Product Owner, Scrum Master i Developerzy. Dzięki obecności całego Zespołu maksymalizujemy wiedzę, którą nabywamy z otrzymanego od Interesariuszy feedbacku.
Na spotkaniu powinni pojawiać się kluczowi Interesariusze (ang. Stake-holder), czyli wszystkie osoby mające interes w sukcesie tworzonego Produktu. Zazwyczaj są to osoby, które płacą za rozwój Produktu, ale również zespoły sprzedażowe, marketingowe, eksperci domenowi etc.
Jest wiele zalet wynikających z bezpośredniego kontaktu całego Zespołu z Interesariuszami. Między innymi Developerzy mogą u źródła uzyskać informacje dotyczące biznesowych aspektów powiązanych z Produktem. Natomiast Interesariusze widzą, kto stoi za tysiącami linijek kodu. Najistotniejszy w tym wszystkim jest jednak fakt budowania relacji i obopólnego zaufania.
Nie zapominajmy również o użytkownikach końcowych, gdyż to oni będą korzystać z Produktu. Zapraszanie użytkowników, szczególnie jeżeli są to osoby z poza firmy, nie zawsze jest możliwe. Jednak jeżeli masz taką możliwość, to jest to zdecydowanie wskazane [4]. O tym jak bezpośredni kontakt członków Zespołu z użytkownikami może wpłynąć na rezultaty pracy pisałam tutaj.
W praktyce w trakcie Review rozmawia się na 3 tematy:
1. Omówienie rezultatów wykonanej pracy
Pierwszym etapem Sprint Review powinno być przejrzyste omówienie pracy wykonanej w trakcie Sprintu oraz osadzenie jej w realiach biznesowych. Każdy wyprodukowany podczas Sprintów Przyrost powinien być krokiem w stronę osiągnięcia Celu Produktu, realizującego strategię firmy [3]. Sprint Review jest dobrą okazją, by przypominać Zespołowi Scrumowemu oraz Interesariuszom do jakiego efektu dążymy.
Podczas Sprint Review należy przedstawić jaki był ustalony przez Zespół Cel Sprintu [3]. Powinien on odpowiadać na pytanie „WHY”, czyli dlaczego Przyrost ma wartość lub jaki jest oczekiwany rezultat (outcome) powiązany z wykonaną pracą.
Informujemy następnie Interesariuszy czy udało się Cel Sprintu osiągnąć. Jeżeli nie, to warto opowiedzieć jaka była tego przyczyna. Być może Zespół napotkał wyzwania w trakcie trwania Sprintu, które uniemożliwiły osiągnięcie Celu. Mówienie o tym może być mało komfortowe, jednak warto to robić by budować zaufanie. Interesariusze czasami mogą pomóc rozwiązać napotkany problem lub wnieść coś wartościowego do rozmowy o potencjalnych rozwiązaniach [3].
By uzyskać pełną transparencję rozmawiamy również o wykonanej pracy, która nie była bezpośrednio związana z Celem Sprintu. Być może Zespół naprawiał błędy zwiększające Długu Technicznego, lub realizował usprawnienia procesu wytwórczego.
Dobrym pomysłem w tej części Review jest pokazywanie miar, które mają znaczenie dla omawianego kawałka pracy. O miarach wartości pisałam tutaj.
2. Prezentacja Przyrostu i feedback
Jednym z punktów Sprint Review jest prezentacja ukończonego Przyrostu. Często wydarzenie jest mylnie przez to traktowane jako „Demo”, mimo, że w rzeczywistości nie jest ono głównym celem tego spotkania [2,3]. Dzięki prezentacji jesteśmy w stanie uzyskać feedback, który umożliwi dalszą dyskusję o kierunku rozwoju Produktu. Pozwoli dokonać adaptacji, by działania Zespołu prowadziły do uzyskania Celu Produktu.
Podczas Review Zespół pokazuje tylko Przyrosty spełniające Definicję Ukończenia (Definition of Done, DoD). Dzięki takiej zasadzie uzyskujemy pełną transparencję dotyczącą tego co zostało zrobione.
Zdarzało mi się jednak pokazywać nieukończoną pracę, jeżeli szczególnie zależało mi na opinii Interesariuszy (np. nowy UI). Podkreślane było jednak dosadnie, że Cel nie został osiągnięty, a prezentowane funkcjonalności nie spełniają Definicji Ukończenia. Dzięki temu pozyskiwaliśmy informacje, które mogliśmy od razu wprowadzić do Produktu przy kończeniu zaległej pracy nad Przyrostem.
By utrzymać skupienie Interesariuszy w celu uzyskania rzetelnych opinii, warto pokazywać tylko te rzeczy, które mają dla nich znaczenie oraz w formie prezentacji live (nie Power Point 🙂 ). Pokazywanie każdego zrealizowane elementu Sprint Backlogu zanudzi Interesariuszy [4]. Wybierając elementy do prezentacji skupiaj się na tych, które mają wpływ na oczekiwany outcome.
Po prezentacji przychodzi czas na feedback i rozmowę o nim. Jako Zespół upewnijcie się, że dobrze rozumiecie przekazane opinie. Zadawajcie pytania, jeżeli opinia na temat konkretnego elementu Przyrostu szczególnie Was interesuje.
3. Rozmowa o planach na przyszły rozwój Produktu
Ostatnim etapem Sprint Review jest rozmowa o dalszych planach na rozwój Produktu.
Istotnym elementem tej rozmowy jest przegląd sytuacji rynkowej. Warto rozważyć czy zaszły zmiany, które mogłoby mieć wpływ na rozwijany Produkt. Tutaj dobrym źródłem rzetelnych informacji mogą być nasi Interesariusze. Review będąc nieformalnym spotkaniem roboczym jest dobrym momentem by śmiało zadawać pytania i inicjować rozmowy o biznesie.
Kolejne na liście do inspekcji i adaptacji mogą być Cel Produktu, Roadmapa, Release plan – jeżeli zasadne, to każdy z elementów może być zaprezentowany i omówiony z Interesariuszami.
Ostatnie, jednak równie ważne to przegląd i wprowadzenie koniecznych zmian do Backlogu Produktu. Razem z Interesariuszami należy przyjrzeć się temu co znajduje się na szczycie, gdyż to właśnie te elementy będą realizowane w kolejnym Sprincie.
Podsumowaniem tych rozważań, może być zaprezentowanie i przedyskutowanie z Interesariuszami wstępnej propozycji Celu kolejnego Sprintu.
Rola Product Ownera Na Sprint Review
Sprint Review jest niezwykle ważnym wydarzeniem z perspektywy roli Product Ownera. Przeprowadzane z poszanowaniem filarów Scruma, czyli inspekcji, adaptacji i przejrzystości, przyniesie informacje będące istotnym wkładem do nadchodzącego Planowania. Zdobywana podczas Review wiedza pomaga Product Ownerowi decydować o kolejności elementów Product Backlogu, tak by maksymalizować wartość Produktu.
Zanim jednak zaczniemy Sprint Review…
Zanim wskoczymy w temat obowiązków Product Ownera podczas Review, ustalmy co powinno się zadziać wcześniej. Sprint Review nie jest spotkaniem podczas którego Product Owner „akceptuje” pracę wykonaną przez Developerów. Product Owner jeszcze przed Review powinien ustalić z Developerami: co zostało ukończone, a co nie; czy Cel Sprintu został osiągnięty, a jeżeli nie, to co o tym zaważyło.
Osobiście lubię pobawić się Przyrostem na własnym środowisku jeszcze przed Review. Przez „dotknięcie” w praktyce zrealizowanej funkcjonalności lepiej rozumiem co w rzeczywistości zostało zrobione. Dzięki temu minimalizuję ryzyko, że coś zaskoczy mnie podczas prezentacji.
A podczas Sprint Review…
Jako osoba odpowiedzialna za kontakt z Interesariuszami oraz zarządzanie Product Backlogiem, zwyczajowo Product Owner jest gospodarzem Sprint Review. Mimo, że Product Owner prowadzi spotkanie, to wydarzenie należy do całego Zespołu [6]. Najlepsze rezultaty osiągniemy, gdy cały Zespół będzie czuł odpowiedzialność za powodzenie tego wydarzenia. Gotowość i otwartość Zespołu do czynnego udziału w spotkaniu oraz współpracy z Interesariuszami będzie pozytywnie wpływać na uzyskaną ze spotkania wartość.
Sprint Review to coś więcej niż spotkanie „Demo”. PO powinien korzystać z możliwości, by jasno komunikować dlaczego wykonujemy dana pracę, jakich rezultatów i wartości dodanej spodziewamy się po dostarczonym Przyroście oraz jak przybliży on Zespół do osiągnięcia Celu Produktu. Sprint Review jest dobrym momentem by rozmawiać o tym czym jest sukces Produktu i jak będziemy go mierzyć [8].
Product Owner powininen z otwartą głową słuchać i uznawać uzyskiwany od Interesariuszy feedback. Wnioski z dyskusji trafiają do Backlogu Produktu, by podczas Refinementu z Zespołem doszczegółowić zadania.
Sprint Review jest często punktem decyzyjnym dla Product Ownera [5]. Przed rozpoczęciem kolejnego Sprintu PO będzie musiał podjąć szereg decyzji dotyczących tego co będzie dalej tworzone przez Zespół. Mowa tu nie tylko o elementach Product Backlogu, ale również: czy wdrażamy Przyrost na środowisko produkcyjne (ang. release); czy należy wykonać pivot i zmienić Roadmapę lub Cel Produktu, bo zmiany rynkowe tego wymagają.
[4] Bardzo podoba mi się zdanie: There is no „I” in the Team. Product Owner jest częścią niehierarchicznego Zespołu Scrumowego, który jest odpowiedzialny za dostarczenie Przyrostu. Gdy coś idzie nie po naszej myśli powodując, że Cel Sprintu nie zostaje osiągnięty, to jest to odpowiedzialność całego Zespołu. Tak samo sukcesy, jak i porażki, powinny być uznawane przez cały Zespół. Product Owner powinien o tym szczególnie pamiętać podczas Review, by budować dobre relacje w Zespole.
Podsumowanie
Sprint Review jest ważnym wydarzeniem Scruma. Daje możliwość inspekcji efektów pracy wykonanej w Sprincie razem z kluczowymi Interesariuszami. Uzyskujemy feedback, możemy uczyć się na jego podstawie i prowadzić wspólne rozmowy, które nakierują Product Ownera na podjęcie dobrych decyzji o kolejnych krokach w rozwoju Produktu. Wszystko z myślą o tym, że każdy Sprint jest małym krokiem w kierunku osiągnięcia Celu Produktu.
Bibliografia
[1] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf
[2] The Purpose of the Five Scrum Events; https://www.scrum.org/resources/blog/purpose-five-scrum-events
[3] Making the Most of the Sprint Review; https://www.scrum.org/resources/blog/making-most-sprint-review
[4] 15 Sprint Review Anti-Patterns — Scrum Anti-Patterns Guide 2022; https://www.scrum.org/resources/blog/15-sprint-review-anti-patterns-scrum-anti-patterns-guide-2022
[5] Sprint Review: Much More Than Just A Demo; https://www.scrum.org/resources/blog/sprint-review-much-more-just-demo
[6] Sprint Review: Being A Good Stakeholder; https://www.scrum.org/resources/blog/sprint-review-being-good-stakeholder
[7] Eight things you should do in your Sprint Review; https://www.scrum.org/resources/blog/eight-things-you-should-do-your-sprint-review
[8] Top 7 Questions to Ask During a Sprint Review; https://www.scrum.org/resources/blog/top-7-questions-ask-during-sprint-reviewychu