Sprint Review – zgodne ze sztuką

book

Wiedza | PROCES

Celem Sprint Review JEST uzyskanie feedbacku od interesariuszy o Inkremencie i zaplanowanie dalszego rozwoju produktu.

Sprint Review jest ukoronowaniem Sprintu – cały zespół spotyka się z tymi, dla których pracowali ciężko przez cały Sprint, aby porozmawiać o wynikach pracy i zdecydować o dalszych krokach.

 

A właściwie tak powinno być, a to co najczęściej obserwuje to:

  • Jest tylko Zespół Scrumowy (czyli PO, SM, DT),
  • Product Owner widzi gotowy produkt po raz pierwszy,
  • Zespoły Deweloperskie tłumaczą się ze Sprint Burndown Chart’a,
  • Słychać bezproduktywne rozmowy na temat velocity,
  • Zamiast Sprint Review jest “demo”, na którym produkt jest tylko pokazywany, a dyskusja o dalszych krokach nie jest częścią agendy,
  • Główna część całego spotkania to ta, w której odbywa się spowiedź tłumacząca, czemu nie wszystko, co zostało zaplanowane, zostało wykonane.

 

Brzmi znajomo? U Ciebie też tak jest? Czytaj dalej, ten artykuł jest o tym, jak zrobić dobre Sprint Review.

 

Celem Sprint Review JEST uzyskanie feedbacku od interesariuszy o Inkremencie i zaplanowanie dalszego rozwoju produktu.

 

Celem Sprint Review NIE JEST:

  • sprawdzenie czy zespół pracuje wydajnie,
  • wyłącznie pokazanie tego co zostało zrobione,
  • podziękowanie za pracę.

 

Aby to wszystko się udało, Przyrost ma być ukończony. Nie ma sensu oglądać bazy danych ani kodu. Zadaniem Zespołu Deweloperskiego jest przygotowanie zrobionego (“Done”) Przyrostu. Może robić niewielki, używalny, ale niekoniecznie jeszcze użyteczny wycinek docelowej funkcjonalności. Z punktu widzenia technologii powinien on jednak przechodzić przez wszystkie warstwy systemu aż po interfejs.

 

Jak więc spotkanie powinno przebiegać:

 

  1. Product Owner opowiada o kierunku rozwoju produktu, celu właśnie kończącego się Sprintu oraz konkretnych funkcjonalności dzięki którym ten cel ma być osiągnięty.
  2. Zespół Deweloperski prezentuje wyniki swojej pracy. Pokazują produkt na środowisku produkcyjnym lub zbliżonym do niego.
    • Nie ma obowiązku prezentowania wszystkiego: lepiej podyskutować o najważniejszych skończonych elementach niż przechodzić litanię naprawionych bugów z prezentacją.
    • Należy powiedzieć o tym czego nie udało się ukończyć.
  3. Interesariusze udzielają informacji zwrotnej. Pytają o szczegóły, proszą o instrukcje, zgłaszają potencjalne ulepszenia.
  4. Adaptacja Product Backlogu (PB). Wszystkie decyzje Product Ownera, które zapadną w oparciu o ten feedback, trafiają do Product Backlogu. Można zrobić notatki bezpośrednio w PB lub gdzieś indziej, a po spotkaniu koniecznie je uporządkować. Ważne aby PB był aktualny.
  5. Co dalej? Na koniec wszyscy wspólnie rozmawiają o tym co dalej z właśnie implementowaną funkcjonalnością, jeżeli nie jest na produkcji to kiedy będzie? Jak zbierzemy informację zwrotną od szerszego grona, jakie statystyki warto zrobić.
  6. Plany długoterminowe. Na koniec można wrócić do planów długoterminowych, zweryfikować kierunek w którym idzie cały produkt, przedyskutować co chcemy osiągnąć w dłuższej perspektywie. Tak aby wizja zarówno krótko jak i długoterminowa była znana wszystkim.

 

W momencie, w którym to wszystko mamy lub wyczerpał nam się timebox, kończymy spotkanie. Zespoły które ja spotkałam najczęściej spędzały na Sprint Review 90min przy dwutygodniowym Sprincie. W ważnych dla rozwoju produktu momentach jak początek lub koniec jakiegoś etapu, może się przydać dłuższa dyskusja. Scrum Guide nie przewiduje poświęcenia temu spotkaniu więcej niż 4 godzin, rzadko widywałam tak długie i jednocześnie produktywne spotkania. O czas należy dbać. Nawet jeżeli w tej chwili spędzacie na review 90 minut, ale macie wrażenie że to spotkanie mogłoby trwać 60 minut i byłoby równie produktywne, należy doprowadzić do tego, aby właśnie tyle trwało.

 

I to wszystko co Scrum nam mówi na temat tego wydarzenia. Jeżeli macie wątpliwości, czy Sprint Review było dobre, to sprawdźcie, czy cel został osiągnięty, czy macie wartościowy feedback, na którym chcecie oprzeć dalszą pracę.

 

Powodzenia.

Powiązane artykuły, mogą Cię też zainteresować!

Jak dawać feedback?

Informacja zwrotna jest szczególnym „darem”. Dany w umiejętny sposób może wiele zmienić, źle użyty rani i zniechęca . Wa...

Nowa aktualizacja Ilustrowanego Scrum Guide - darmowy e-book do ściągnięcia

Scrum: jest lekki, łatwy do zrozumienia i trudny w implementacji. Dlatego 7 listopada 2017 Jeff Sutherland i Ken Schwab...

Prosty przepis na udany produkt

Jesteś głową organizacji. Chcesz tworzyć świetne produkty. Scrum wydaje się rozsądnym wyborem. Przepis wydaje się pro...

Udana sesja feedbackowa

Udzielanie informacji zwrotnej, to jeden z najważniejszych czynników, pozwalających na rozwój osobisty i poprawę partner...