Opublikowano: 14.11.2018

Po co nam Sprint Review?

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 Sprint Review. Pora pochwalić 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 podczas 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 Rejestru, które zostały Skończone. Zebranie informacji zwrotnej i udzielenie odpowiedzi na pytania.
  • Omówienie informacji zwrotnej otrzymanej z rynku oraz wpływu tych danych na dalsze prace.
  • Omówienie Rejestru Produktu, postępu prac, budżetu i harmonogramu.
  • Dyskusja na temat dalszych kroków i zakresu następnego Sprintu.

Czego unikać na 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”. 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śmy 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 i Zespołu. Co więcej taka formalna akceptacja nie ma też dużej wartości w Scrumie i jest zachowaniem wyuczonym przez “Gry Kontraktów” w klasycznych modelach zarządzania. W modelach kaskadowych wprowadzenie zmiany do już “zaakceptowanego” produktu wiąże się z kosztami finansowymi (“zmiana jest dodatkowo płatna”), czasowymi (“zgłosić i wycenić zmianę”) i 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 Rejestru. Dlatego PO może się zdecydować, że stworzy PBI na zmianę tekstu, ale nie umieści go na samej górze Rejestru, 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ć wersji użytkownikom to wystarczy, że przekaże tą informację Zespołowi.

Jak może wyglądać Sprint Review?

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

Dobry Przegląd wymaga wzajemnego zaufania. Jeżeli Zespół będzie się czuł zagrożony, to jest ryzyko ukrywania błędów i nieskończonej pracy. 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 oni 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ą wspólnie pokazywały skończone PBI. Najlepsze zespoły jakie znam nie skupiają się na dostarczonych funkcjach, ale na wartości. 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 z Przeglądu będą stanowiły wprowadzenie do planowania kolejnego Sprintu.

Wynik Review Sprintu

Na Przeglądzie dostajemy wiedzę na temat produktu. Dlatego w wyniku spotkania zakutalizujemy Rejestr Produktu. Te Elementy, które Zespół Skończył są zamykane (usuwane z Rejestru). Jeżeli jakiegoś PBI nie udało się Skończyć, to wraca on z powrotem do Rejestru. Często będzie Skończony w następnym Sprincie, chociaż to do PO należy ostateczna decyzja. Usuwane z Backlogu są również Elementy, które zostały ukończone „przy okazji” trwania Sprintu. Poza tym, w trakcie Przeglądu przyjdą wam do głowy nowe pomysły, które dodacie do Rejestru, a czasami okaże się, że pewne pomysły nie mają już sensu, więc je usuniecie. Oczywiście cały Rejestr 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.

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)

 

Tomasz Wykowski

Tomasz Wykowski

Międzynarodowy gawędziarz i jedyny polski trener Scrum Alliance. Ciągle poszukuje nowych rozwiązań.

Podobne

Komentarze (0)

Brak komentarzy, dodaj pierwszy!

Dodaj komentarz