Po co nam Sprint Review?

Hurra! Pracujemy iteracyjnie! Ustaliliśmy ile ma trwać nasz Sprint, zaplanowaliśmy go i codziennie sprawdzaliśmy czy wciąż jesteśmy na dobrej drodze do osiągnięcia celu. Nadszedł koniec Sprintu a wraz z nim Przegląd Sprintu, czyli Sprint Review. Pora porozmawiać o tym jak nam poszło, zebrać informację zwrotną i zidentyfikować potencjalne obszary rozwoju. Inaczej mówiąc celem Sprint Review jest Inspekcja i Adaptacja Produktu. Dlatego na Sprint Review chcę widzieć jak najwięcej osób zainteresowanych produktem. Zarówno z naszej firmy, jak i od strony klientów czy użytkowników.

Jak osiągnąć cel Sprint Review?

Aby podejmować właściwe decyzje musisz zebrać dane. Dlatego warto uwzględnić podczas Review następujące elementy:

• Omówienie jak wyglądał Plan Sprintu (i ewentualne zmiany w trakcie Sprintu). Co zostało Skończone zgodnie z Definicją Ukończenia (DoD), a co nie.
• Przedstawienie przez Zespół co się udało, jakie problemy się pojawiły i jak zostały zaadresowane.
• Pokazanie działania Elementów Backlogu Produktu, które zostały Skończone. Zebranie informacji zwrotnej i udzielenie odpowiedzi na pojawiające się pytania.
• Omówienie informacji zwrotnej otrzymanej z rynku oraz wpływu tych danych na dalsze prace.
• Omówienie Backlogu Produktu, postępu prac, budżetu i harmonogramu.
• Dyskusja na temat dalszych kroków i zakresu następnego Sprintu.

Czego unikać na Sprint Review?

Jednym z najczęściej popełnianych błędów jest raportowanie przez członków Zespołu co zrobili w ostatnim Sprincie, podczas gdy Product Owner łaskawie akceptuje (lub nie) kolejne Elementy. Inaczej mówiąc kolejni członkowie spowiadają się przed PO ze „swoich PBI”, a reszta czeka na swoją kolej. Dlaczego jest to błędem? Po pierwsze nie mamy tu żadnej inspekcji i adaptacji. W najlepszym wypadku, jedyna informacja zwrotna, jaka dociera do Zespołu, to fakt, że odgadli co PO miał na myśli. Po drugie, Product Owner powinien być dostępny dla Zespołu w trakcie Sprintu, więc jeżeli widzi produkt po raz pierwszy na Review to mamy poważny problem z komunikacją i dostępnością PO dla Zespołu. Po trzecie wreszcie, PO ma współpracować z Zespołem a nie nim zarządzać. Odpowiedzialność za dostarczenie właściwych rozwiązań spoczywa po równo na barkach Ownera jak i Zespołu.

Co więcej taka formalna akceptacja przez PO nie ma też dużej wartości w Scrumie i jest zachowaniem wyuczonym przez „Grę Kontraktów” (Contract Game) w klasycznych modelach zarządzania. W tradycyjnych, predyktywnych modelach pracy (takich jak Waterfall) wprowadzenie zmiany do już „zaakceptowanego” produktu wiąże się z kosztami finansowymi („ta zmiana będzie dodatkowo płatna”), czasowymi („ trzeba zgłosić, przeanalizować, wycenić i wprowadzić zmianę”), a nawet moralnymi („analiza nie została przeprowadzona właściwie skoro ominęliśmy tą informację”). W Scrumie sprawa wygląda inaczej. Jeżeli PO nie „zaakceptuje” PBI, bo na przykład nie podoba mu się wyświetlany tekst, to Zespół i tak musi poświęcić czas na jego zmianę w następnym Sprincie. Jeżeli natomiast PO nie ma „władzy akceptacji”, to przecież i tak może stworzyć nowy PBI na zmianę tekstu i poprosić Zespół, żeby go zrobił w następnym Sprincie. Ten nowy PBI zajmie dokładnie tyle samo czasu co poprawa błędu, bo to dokładnie ta sama praca. Tylko nazewnictwo inne. I relacje z PO też, bo przechodzimy z modelu służebnego do partnerskiego, gdzie PO i Zespół grają razem do jednej bramki. Na koniec wreszcie, ten nowy PBI, może być ważny dla PO, ale nie aż tak, jak pozostałe elementy Backlogu Produktu. Dlatego PO może się zdecydować, że stworzy PBI na zmianę tekstu, ale nie umieści go na samej górze Backlogu, tylko zrobi go dopiero jak uruchomi płatności online. No i najważniejsze - to Product Owner decyduje o wydaniu produktu, więc jeśli uważa, że bez tej zmiany nie można udostępnić aktualnej wersji użytkownikom to wystarczy, że przekaże tą informację Zespołowi.

Jak może wyglądać Sprint Review?

Dobry Przegląd Sprintu to rozmowa między Zespołem, PO i interesariuszami na temat produktu. Chciałbym, żeby Zespół pokazał działający produkt i jego rezultaty, a nie prezentację w Power Poincie. Nie może to być samo „demo”, ale zebranie informacji zwrotnej i dyskusja na temat dalszego rozwoju produktu. Spotkanie powinno być nieformalne – Zespół nie powinien przeznaczyć więcej niż godzinę na przygotowanie się do Sprint Review. Jeżeli to możliwe, pozwól użytkownikom i interesariuszom używać nowych funkcji.

Sprint Review wymaga wzajemnego zaufania. Jeżeli Zespół będzie się czuł zagrożony, to jest ryzyko ukrywania błędów i nieskończonej pracy oraz ogólnego malowania trawy na zielono. Dlatego Scrum Master poza moderowaniem spotkania musi dbać o atmosferę i poczucie bezpieczeństwa wszystkich uczestników. Zwłaszcza, że jest to spotkanie najczęściej angażujące największą ilość ludzi z Twojej firmy (i nie tylko), więc jeżeli jest prowadzone nieefektywnie to cierpi więcej osób i sumarycznie tracicie więcej czasu. Rekomendowana długość spotkania to 1 godzina na tydzień Sprintu, czyli Przegląd nigdy nie powinien trwać dłużej niż 4 godziny.

Członkowie początkujących Zespołów będą często opowiadali co sami zrobili, co może wyglądać albo jak spowiedź, albo jak konkurs piękności. Bardziej doświadczone Zespoły skupią się na wspólnie wykonanej pracy i będą razem pokazywały skończone PBI. Najlepsze zespoły jakie znam zamiast o dostarczonych funkcjonalnościach opowiadają o osiągniętej wartości biznesowej. Pokazują jak zmieniły się zachowania klientów, jakie metryki udało się podnieść lub obniżyć i czego nowego dowiedzieliśmy się o naszym rynku i konkurencji. Oczywiście wnioski ze Sprint Review będą stanowiły wprowadzenie do planowania kolejnego Sprintu.

Wynik Sprint Review

Na Sprint Review dostajemy wiedzę na temat produktu. Dlatego w wyniku spotkania zakutalizujemy Backlog Produktu. Te Elementy, które Zespół Skończył są zamykane (czyli usuwane z Backlogu). Jeżeli jakiegoś PBI nie udało się Skończyć, to wraca on z powrotem do Backlogu. Często będzie dokończony w następnym Sprincie, chociaż to do PO należy ostateczna decyzja na temat jego priorytetu. Usuwane z Backlogu są również Elementy, które zostały ukończone „przy okazji” trwania Sprintu. Poza tym, w trakcie Sprint Review przyjdą wam do głowy nowe pomysły, które dodacie do Backlogu, a czasami okaże się, że pewne pomysły nie mają już sensu, więc je usuniecie. Oczywiście cały Backlog będzie na nowo porządkowany na podstawie świeżo zdobytej wiedzy.

Jeżeli macie roadmapę produktową albo Plan Wydania to również będą uaktualniane.

Na koniec Sprintu Product Owner ma prawo zdecydować o:

• Kontynuacji pracy, czyli rozpoczęciu następnego Sprintu
• Wstrzymaniu prac, gdy okaże się, że koszty przewyższają planowane zyski
• Dostarczeniu Produktu wszystkim lub wybranym klientom, czyli o Wydaniu (Release)

Oczywiście w wielu firmach nie są to formalne decyzje, które są omawiane na każdym Sprint Review.

A po zakończonym Przeglądzie pora na Retrospektywę Sprintu.