Sprint Review: Jak przebiega Review w Scrum i Agile?
Najbardziej oczywistą aktywnością na spotkaniu Sprint Review jest demonstracja funkcjonalności zbudowanej w poprzednim Sprincie. Jednak dobre Sprint Review to coś więcej niż tylko demonstracja. Przyjrzyjmy się wspólnie agendzie spotkania Review.
Tworzenie właściwych warunków dla Review
Product Owner rozpoczyna spotkanie Sprint Review, witając wszystkich uczestników. Wystarczy, jeśli powie coś w stylu: „Dziękuję, że wszyscy tu jesteście."
Jeśli obecni nie znają się nawzajem, Product Owner może poprosić ich o krótkie przedstawienie się. Na początku nowej inicjatywy wytwarzania produktu runda prezentacyjna jest generalnie dobrym pomysłem. Product Owner wie, że Joe z marketingu to Joe z marketingu; ale członkowie zespołu mogą tego nie wiedzieć.
Ponadto warto, aby wszyscy uczestnicy krótko się przedstawili, gdy od czasu do czasu do Sprint Reviews dołączają nowi uczestnicy. Na przykład Joe z marketingu może brać udział tylko w Sprint Reviews dwóch Sprintów, podczas których zespół pracował nad funkcjami związanymi z marketingiem.
Przedstawianie się powinno być naprawdę krótkie i zwięzłe. „Cześć, jestem Mike i jestem developerem. Pracowałem nad funkcjami koszyka zakupów" – to prawie za dużo. „Cześć, jestem Mike i jestem developerem" – w większości przypadków wystarczyłoby. Gdy jednak zespół osiągnie określony rozmiar, może być pomocne dla interesariuszy, aby krótko dowiedzieć się, nad czym pracował każdy z osobna.
Po powitaniu i ewentualnie potrzebnej rundzie prezentacyjnej na początku Product Owner może jeszcze ustalić kilka zasad lub ogłosić oczekiwania co do Sprint Review. Na przykład niektórzy Product Ownerzy uważają za ważne, aby przypomnieć o zachowaniu uprzejmości również podczas Sprint Review. Jeśli komuś nie podoba się, jak funkcja została zaimplementowana, oczywiście może to powiedzieć; nie powinien jednak nazywać implementacji „głupią". Tak, oczywiście wszyscy to wiemy, ale czasem trzeba o tym przypomnieć.
W zależności od liczby uczestników i wielu innych czynników, Product Owner może też wyjaśnić obecnym, że podczas Review szuka się feedbacku do dotychczas zbudowanych funkcji, ale nie jest to czas i miejsce na całkowite przeprojektowanie funkcji.
Gdy skończysz z intro i zasadami Review, czas przejść do kolejnego punktu agendy.
Co jest demonstrowane podczas Review – a co nie?
W tym miejscu wiele zespołów przechodzi bezpośrednio do demonstracji. Zalecam, żeby Product Owner najpierw dał krótki przegląd tego, co ma być zademonstrowane i co nie.
Aby uniknąć sytuacji, w której Product Owner jedynie odczytuje listę elementów, której uczestnicy nie mogą śledzić, powinno być to pokazane wszystkim na monitorze lub projektorze. Albo wydrukować listę z wyprzedzeniem dla tych, którzy ewentualnie chcieliby mieć kopię.
Osobiście chętnie wysyłam te informacje wieczorem przed spotkaniem jako dokument Word w e-mailu do wszystkich potencjalnych uczestników spotkania Sprint Review. Daje to ludziom możliwość zobaczenia z wyprzedzeniem, co ma być zademonstrowane. Dzięki temu każdy może sam zdecydować, czy warto dla niego/niej wziąć udział w Sprint Review.
Poniższa tabela pokazuje informacje, które moim zdaniem są istotne dla każdego elementu Product Backlogu. Zaproponowałbym wymienienie elementów w kolejności, w jakiej będą demonstrowane. Można to jednak zmieniać spontanicznie według potrzeb.
Pierwsza kolumna w tabeli to opis danego elementu. Wstawiana jest tam User Story lub inny opis. Następnie rozmiar elementów – zwykle w Story Points. Potem status elementów. Chodzi głównie o to, czy są ukończone, czy nie. Ale wszystko inne, co wydaje się ważne w tym kontekście, można tam też dodać. Ostatnia kolumna wskazuje, czy dany element będzie demonstrowany, czy nie.
Możesz się zastanawiać, po co w ogóle umieszczać na liście elementy, które nie mają być demonstrowane. W powyższej tabeli zamieściłem kilka przykładów. Oczywiste jest, że element, który wprawdzie był włączony do Sprintu, ale potem został porzucony, nie może być demonstrowany. Umieściłem też poprawkę błędu, która dotyczy jedynie aktualizacji znaku na ekranie – ten element też nie jest przeznaczony do demonstracji.
Całkiem możliwe, że jeden lub więcej uczestników zapyta o element, który w zasadzie nie był przeznaczony do demonstracji. Jeśli to nastąpi, możesz ten element spokojnie przedstawić razem z innymi elementami. Chodzi nie o to, żeby unikać pokazywania określonych elementów, ale o szanowanie czasu ludzi poprzez nieprezentowanie im elementów, do których nie potrzebujesz feedbacku.
W przykładowej tabeli umieściłem element Product Backlogu, który został dodany w trakcie Sprintu. Uważam za sensowne, aby można było rozpoznać, które elementy były od początku zaplanowane w Sprincie, a które zostały dodane w jego trakcie. Jeśli zdarza się często, że elementy są dodawane w trakcie Sprintu, można zastanowić się nad dodaniem kolumny do tabeli i zaznaczaniem tam, czy elementy były zaplanowane, czy dodane później.
Dodatkowo można wstawić po prawej stronie kolumnę wskazującą, czy elementy zostały zaakceptowane przez uczestników spotkania Review, są gotowe do releasu itp. Jest to szczególnie sensowne, gdy takie decyzje są oficjalną częścią Sprint Review.
Postaraj się nie poświęcać zbyt wiele czasu na tę część agendy. Celem nie jest tutaj zbieranie feedbacku do elementów ani mówienie o tym, dlaczego zaplanowany element został tylko częściowo wdrożony. Ta lista służy jedynie do przedstawienia zawartości spotkania. Po tym, jak Product Owner przedstawi tę listę, czas przejść do głównej części Sprint Review: demonstracji.
Demonstrowanie nowych funkcjonalności
To jest serce każdego spotkania Sprint Review. Jeśli już prowadzisz Sprint Reviews, możliwe też, że to jedyna część agendy, którą faktycznie realizujesz.
W tej części Sprint Review przechodzisz krok po kroku przez listę elementów, którą wcześniej pokazałeś obecnym. Pamiętaj, że sens i cel spotkania Sprint Review polega na uzyskaniu feedbacku.
Nie ma stałej zasady, kto powinien prowadzić demonstrację. W niektórych przypadkach przejmie to Product Owner. Zawsze proponowałbym to, gdy szczególnie trudni interesariusze biorą udział w Review. W innych przypadkach poszczególni członkowie zespołu demonstrują samodzielnie elementy, nad którymi pracowali. Prawie każda wariantacja jest tu dozwolona. Po prostu eksperymentuj z tym i sprawdź, co najlepiej działa dla Twojego zespołu.
Omawianie najważniejszych punktów
Gdy wszystkie ukończone elementy Product Backlogu zostaną zademonstrowane, omawiane są główne wydarzenia lub problemy tego Sprintu.
Dyskusja może być moderowana przez Scrum Mastera lub Product Ownera. Z mojego doświadczenia oba modele działają równie dobrze. Osobiście mam jednak lekką tendencję do tego, żeby Scrum Master przejął tę część spotkania.
Do tego momentu w Review Product Owner będzie mówił znacznie więcej niż Scrum Master. Dlatego uważam za dobry wyważenie, gdy Scrum Master moderuje tę część agendy. Poza tym jest to ściśle mówiąc zwykle dyskusja bardziej o procesie niż o samym produkcie. Dlatego nieco bardziej wchodzi w zakres Scrum Mastera.
Prezentowanie kolejnych elementów Product Backlogu
Ostatni punkt na agendzie Sprint Review powinien stanowić dyskusja o kolejnych pracach w Product Backlogu. Ponieważ celem Sprint Review jest zbieranie feedbacku do prac z aktualnego Sprintu, często wpływa to też na prace kolejnych Sprintów.
Jeśli interesariuszom bardzo podobają się na przykład nowe ekrany, Product Owner może chcieć szybko dostosować inne obszary produktu do nowego designu. Albo też interesariuszowi nie podoba się sposób, w jaki funkcje zostały zaimplementowane. Wtedy kolejny Sprint może zostać wykorzystany na naprawienie tych punktów, zamiast kontynuowania z kolejnymi elementami (jak by nastąpiło bez Sprint Review).
Product Owner rozpoczyna dyskusję prezentując kolejne potencjalne elementy z Product Backlogu. Mówi wtedy może coś w stylu: „Na ekranie widzicie dziesięć elementów, które przewidziałem na kolejny Sprint. Chciałbym jednak jeszcze dodać element XY, który pojawił się dzisiaj. Prawdopodobnie wstawię go jako element nr 3."
Product Owner pyta następnie uczestników o ich opinię na temat tej listy. Jednak moim zdaniem Product Owner nie powinien dokonywać priorytetyzacji podczas Sprint Review na podstawie tych komentarzy. Jest ku temu kilka powodów. Product Owner może potrzebować trochę czasu, żeby zastanowić się nad tym, co zostało powiedziane. Lub może chcieć zebrać oceny od zespołu dotyczące zmian, o które poproszono w Review itd. Product Owner zbiera więc opinie podczas Sprint Review i podejmuje ostateczne decyzje spokojnie po spotkaniu.
Zamykanie Review
Zakończ spotkanie, po prostu dziękując wszystkim za udział. Zastanów się również, czy nie chcesz podziękować całemu zespołowi za pracę w ostatnim Sprincie, lub od czasu do czasu jednemu lub dwóm członkom zespołu, którzy osiągnęli szczególnie dobre wyniki. Następnie przypomnij wszystkim, kiedy i gdzie odbędzie się następne Sprint Review.
Po Sprint Review
Choć nie należy to bezpośrednio do agendy Sprint Review, należy zadbać o to, aby wszystkie nowe Product Backlog Items zostały przeniesione do narzędzia zespołu lub zapisane na karteczkach Post-It i umieszczone na tablicy Scrum Board.
