Sprint Review to nie Sprint Demo!

Wielu z nas, praktykujących Scrum błędnie nazywa Przegląd Sprintu (ang. Sprint Review), jako Sprint Demo (albo po prostu Demo). Czy jest to tylko kwestia semantyki? Z mojego punktu widzenia, Przegląd Sprintu jest często wydarzeniem, które nie zostało prawidłowo zrozumiane (jego cel) – potencjał tego wydarzenia nie został jeszcze w pełni ujawniony. Prawdą jest, że prezentacja Przyrostu (demo)  jest najistotniejszym elementem Sprint Review, ale nie jedynym – Sprint Review jest czymś więcej. Dowiedzmy się, dlaczego.

Przegląd Sprintu ma na celu uczynienie Przyrostu i Backlogu Produktu bardziej przejrzystym (transparentnym). Zespół Scrumowy i interesariusze analizują oba wcześniej wymienione elementy (Przyrost i Backlog Produktu), i dzielą się spostrzeżeniami i wnioskami. Patrząc na warunki rynkowe, zmiany organizacyjne, budżet, harmonogram wspólnie decydują o kolejnych krokach.



Sama demonstracja Przyrostu jest istotną częścią Przeglądu Sprintu, nie jest ona jednak celem samym w sobie. Najważniejszym elementem wydarzenia jest pogłębiona rozmowa i współpraca między uczestnikami, która umożliwia produktywna adaptację i inspekcję. Maarten Dalmijn w swoim artykule Why you should never call the Sprint Review the Sprint Demo, przytacza analogię nazywania Przeglądu Sprintu jako Sprint Demo – jest to jak nazywanie dziewięciodaniowego posiłku przystawką – przystawka zaczyna posiłek i jest ona tylko ułamkiem wiktułałów, których możemy oczekiwać. Nazywanie Review jako demo może wydawać się tylko semantyką, jednak powoduje ona, że wszyscy uczestnicy wydarzenia mają zły stan umysłu / wyobrażenie (ang. state of mind). 

W pewnym sensie Przegląd Sprintu ma dostarczyć odpowiedź na pytanie: „Na podstawie tego, czego się nauczyliśmy o minionym Sprincie oraz analizy czynników zewnętrznych (np. uwarunkowania rynkowe, zachowanie naszych użytkowników), jakie są kolejne kroki?”. Odpowiedź na to pytanie dostarcza nieoceniony wkład w Planowanie Sprintu.

Jakie są cechy dobrego Przeglądu Sprintu?

Korzystając z mojego doświadczenia oraz artykułu Barryego Overeem, dobry Przegląd Sprintu powinien cechować się następującymi elementami:

  • Sprint Review jest okazją do inspekcji i adaptacji, do praktykowania empiryzmu 
    • inspekcja powinna dotyczyć takich elementów jak: Sprint, Rejestr Produktu, Przyrost, rynek, budżet, harmonogram, możliwości wytwórcze (ang. capabilities),
    • adaptacja powinna dotyczyć takich elementów jak: Rejestr Produktu, plan wdrożeń (ang. release plan),
  • uczestnicy wydarzenia są aktywnie zapraszani do dzielenia się opiniami, sugestiami i pomysłami, 
  • Backlog Produktu jest dostosowywany na bieżąco w miarę pojawiania się nowych informacji (czy to bazujących na obserwacji rynku, czy Przyrostu),
  • nie tylko zespół deweloperski bierze aktywny udział w Review – Przegląd Sprintu dotyczy całego Zespołu Scrumowego (w tym Właściciela Produktu – Product Ownera, UXa, SMa, Lidera, itp. ról), który dzieli się Przyrostem z interesariuszami,
  • Właściciel Produktu omawia Backlog Produktu i podaje prawdopodobne daty ukończenia kolejnych releasów na podstawie postępów z minionych Sprintów,
  • decyzje, które mogą (czasami powinny) mieć miejsce
    • zatrzymywanie / wstrzymywanie rozwoju produktu,
    • finansowanie następnego Sprintu,
    • potrzebnego większego budżetu na wydatki związane z rozwojem produktu,
  • w spotkaniu biorą udział użytkownicy końcowi, którzy faktycznie są osobami, które korzystają z produktu,
  • Właściciel Produktu lub Zespół Deweloperski pokazuje faktycznie skończone funkcje – Przyrost jest elementem, który w każdej chwili może pojawić się na środowisku produkcyjnym,
  • jest też możliwa praktyka, która wykracza poza definicje zawarte w Scrum Guide, że Product Owner z Zespołem Deweloperskim odbierają Przyrost między sobą jeszcze przed “oficjalnym” Przeglądem Sprintu
    • demo odbywa się przed spotkaniem,
    • PO wraz z zespołem sprawdzają, czy nowe funkcje działają,
    • w trakcie tego spotkania, bazując na wykonanych czynnościach powstaje scenariusz Przeglądu, który krok po kroku będzie prowadził prezentującego, jak i interesariuszy w trakcie Review, po różnych przypadkach użycia produktu,

Jak widzicie powyżej, lista ta podaje właśnie te elementy, które odróżniają Sprint Demo od Sprint Review. Przegląd Sprintu nie polega tylko i wyłącznie na prezentacji tego, co Zespół Deweloperski wytworzył w minionej iteracji, ale jest także deltą (czymś więcej), która wnosi dużą wartość i jest nierozłącznym elementem Przeglądu.

Wskazówki (hinty) pomocne w Przeglądzie Sprintu

  • na początku wydarzenia, powiedz jaki jest cel Przeglądu Sprintu

Upewnij się, że wszyscy go rozumieją – że wydarzenie dotyczy zbierania opinii i wspólnej rozmowie o produkcie i Przyroście, a nie „sprzedaży produktu” lub „przyjmowania wykonanej pracy”.

  • poproś członków zespołu deweloperskiego, aby “sparowali” się z interesariuszami i wspólnie sprawdzili Przyrost

Zamiast pokazywać Przyrost na forum, daj każdemu interesariuszowi klawiaturę / urządzenie i pozwól im eksperymentować pod kierunkiem konkretnego dewelopera.

  • unikaj prezentacji zrobionej w PowerPoint lub zrzutów ekranu

Próba użycia Przyrostu produktu jest najlepszym sposobem na weryfikację założeń i interpretacji deweloperów, użytkowników i innych zainteresowanych stron.

  • upewnij się, że wszyscy deweloperzy biorą udział w Przeglądzie Sprintu

Sprint Review jest idealną okazją do zebrania opinii na temat produktu ulepszonego / rozszerzonego / zaktualizowanego przez deweloperów podczas Sprintu. 

  • zaproś prawdziwych użytkowników 

Są to osoby, które faktycznie będą korzystać z produktu i są w stanie określić, czy produkt „działa dobrze”. Staraj się jednak unikać przekształcenia rozmowy z użytkownikami w user acceptance test (UAT)

  • zmień format wydarzenia

Zmieniaj format Przeglądu Sprintu w zależności od kontekstu. Czasami dobrze jest zrobić różne „stragany”, na których deweloperzy pokazują poszczególne aspekty produktu. Czasami najlepiej sprawdza się pokazywanie Przyrostu przez jedną osobę, w centralnym punkcie. Zespół Scrumowy powinien stale poszukiwać najlepszego sposobu zbierania informacji zwrotnych od interesariuszy.

  • w ramach Podsumowania zapytaj uczestników, co można zrobić, aby (dalej) poprawić wartość, jaką daje Przeglądu Sprintu, bazując na jego dotychczasowym przebiegu

Podsumowanie

W tym wpisie chciałem Wam pokazać, że w Przeglądzie Sprintu nie chodzi tylko o pokazanie Przyrostu interesariuszom. Chociaż demo z pewnością może być (jest) częścią Przeglądu Sprintu, nie uchwyci tego, na czym tak naprawdę polega Przegląd Sprintu: współpraca pomiędzy Zespołem Scrumowym i interesariuszami w celu wykonania inspekcji i adaptacji oraz podjęcia decyzji o najistotniejszych kolejnych krokach.

Przegląd Sprintu to miejsce, w którym można omówić zmiany na rynku, zaktualizować harmonogram planowanych wydań, omówić Backlog Produktu i co powinniśmy jako zespół wziąć pod uwagę przy następnym Planowaniu. 

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x