Przegląd sprintu – sprint review
Co to jest?
Pod koniec Sprintu w SCRUM przeprowadza się Przegląd Sprintu (ang. sprint review), będący jedną z aktywności inspekcyjno adaptacyjnych.
Podczas Przeglądu Sprintu prezentowany jest Przyrost, będący potencjalnie gotowym do wdrożenia produktem. Spotkanie to daje możliwość pochwalenia się Zespołowi Scrumowemu wytworzonym produktem.
Zespół powinien zaprezentować jedynie pracę, która została ukończona i spełnia kryteria przyjęte w Definicji Ukończenia.
Wykonana praca powinna być przedstawiana z uwzględnieniem historyjek użytkownika przyjętych do realizacji w Sprincie i ich Kryteriów Akceptacyjnych.
Ważne jest to, iż celem spotkania jest prezentacja Przyrostu i weryfikacja wymagań dla obrania najlepszego kierunku rozwoju produktu, a nie szukanie winnych w sytuacji, gdy założony Cel Sprintu nie został osiągnięty.
Kto bierze udział w review ?
W Przeglądzie Sprintu uczestniczy cały Zespół Scrumowy, lecz mogą w nim uczestniczyć także inne zainteresowane Przyrostem, takie jak wewnętrzni i zewnętrzni interesariusze oraz inne zespoły wewnętrzne.
Spotkanie to umożliwia Zespołowi Scrumowemu otrzymanie informacji zwrotnej na temat produktu od osób, które na co dzień nie mają możliwości uczestniczyć w jego rozwoju. Zapraszając osoby spoza Zespołu Scrumowego na Przegląd Sprintu warto kierować się wyczuleniem na potrzeby tych osób względem realizowanego Celu Sprintu.
Ile trwa przegląd sprintu?
Długość trwania spotkania Przeglądu Sprintu jest ograniczony czasowo i zależy od przyjętej długości trwania Sprintów – przykładowo dla Sprintu trwającego cztery tygodnie, Przegląd Sprintu nie powinien być dłuższy niż 4 godziny, a dla sprintu trwającego 2 tygodnie – dłuższy niż 2 godziny.
Rola product owner ‘a w czasie przeglądu sprintu
Bardzo istotna jest rola Właściciela Produktu podczas Przeglądu Sprintu. Jest on jednym z współautorów wytworzonego produktu, dlatego nie powinien być zaskoczony efektami pracy Zespołu Deweloperskiego ani negować ich osiągnięć.
Istotną rolę ogrywają też zewnętrzni obserwatorzy spotkania, ponieważ często widząc efekty pracy Zespołu, mogą dać obiektywne uwagi do produktu, które następnie Właściciel Produktu może, ale nie musi, uwzględnić w Backlog Produktu.
Literatura:
- scrum guide
- Tworzenie oprogramowania w 30 dni; K. Schaber, J. Sutherland
- Scrum, praktyczny przewodnik po najpopularniejszej metodyce Agile, K. Rubin
- Scrum, o zwinnym zarządzaniu projektami, M. Chrapko