Każdy sprint kończy się Spotkaniem Przeglądowym Sprintu (ang. Sprint Review Meeting), gdzie zespół prezentuje potencjalnie wykonalne przyrosty produktu.
Na końcu każdego sprintu odbywa się Spotkanie Przeglądowe Sprintu. W trakcie spotkania Zespół Scrum pokazuje, co osiągnął podczas sprintu. Na ogół przybiera to formę demonstracji nowych cech i funkcjonalności produktu. Uczestnicy Przeglądu Sprintu to zazwyczaj Właściciel Produktu, Zespół Scrum, Mistrz Scrum, kierownictwo, klienci a także inżynierowie z innych projektów. Podczas przeglądu sprintu ocenia się projekt względem celu sprintu ustalonego na Spotkaniu dot. Planowania Sprintu. Sytuacją pożądaną jest, aby zespół wykonał każdą pozycję Product Backloga przeniesioną do sprintu, ale ważniejsze jest, aby osiągnąć ogólny cel sprintu.
Przegląd sprintu daje wszystkim wnoszącym wkład w wysiłek mający na celu stworzenie produktu szansę inspekcji i adaptacji tego, co zostało zbudowane do tej pory. W trakcie tej aktywności można obiektywnie spojrzeć na bieżący stan produktu i ujawnić wszelkie niewygodne prawdy na jego temat. Jest to czas zadawania pytań, czynienia obserwacji i dyskutowania na temat tego, jaką drogą iść dalej w zaistniałych realiach.
Przegląd sprintu ze względu na pomoc, jaką daje organizacji w tworzeniu pomyślnego produktu, jest jedną z najistotniejszych pętli zdobywania wiedzy w środowisku Scrum. A ponieważ sprinty są krótkie, pętla ta jest bardzo szybka, co pozwala na częste poprawki kursu i nadawanie produkcji właściwego kierunku. Gdybyśmy zamiast tego odraczali proces pętli zwrotnej do znacznie późniejszego momentu i zakładali, że wszystko przebiega zgodnie z pewnym planem bazowym, otrzymalibyśmy zapewne to, do czego wielu jest przyzwyczajonych — zaskoczenie, rozczarowanie i frustrację” [1].
Przegląd sprintu pomaga w tworzeniu udanego produktu. Daje zespołowi scrumowemu szansę na współpracę z interesariuszami, okazję do sprawdzenia stopnia rozwoju produktu oraz możliwość podjęcia decyzji o jego dalszych losach. Nie trzeba zdawać się jedynie na przypuszczenia, że wszystko idzie zgodnie z planem. (…)
Jeśli jesteś właścicielem produktu, masz za zadanie rozpocząć zebranie, porównując przyrost do celu sprintu i sprawdzając w ten sposób, czy cel został osiągnięty, a postęp poczyniony. Upewnij się, że dokładnie zapoznałeś się z przyrostem produktu oraz zaakceptowałeś lub odrzuciłeś każdy element rejestru produktu, nad którym pracował zespół. Najlepszą metodą jest przeprowadzenie kilku testów. Pamiętaj: akceptuj tylko te elementy rejestru, które są zgodne z definicją pojęcia „gotowe”, a w przypadku korzystania z user stories spełniają założone kryteria. Nigdy nie akceptuj elementów nieskończonych lub wadliwych. Tego typu elementy otrzymują zero punktów i są z powrotem wpisywane do rejestru produktu. Pamiętaj, że prowadzenie spisu częściowo wykonanej pracy powoduje rozmycie przejrzystości postępu oraz prowadzi do anomalii w wykresie spalania danego wydania” [2].
Spotkanie przeglądowe sprintu jest celowo bardzo nieformalne, na ogół zakazuje się stosowania slajdów w PowerPoincie i daje się nie więcej niż dwie godziny czasu na przygotowanie do tego spotkania. Spotkanie przeglądowe sprintu nie powinno przerodzić się w zakłócenie uwagi czy drogę okrężną dla zespołu; powinno być ono raczej naturalnym rezultatem sprintu.

 

Cały cykl artykułów na temat metodyki Scrum jest pod adresem: https://www.michalwolski.pl/tag/metodyka-scrum/ . Zapraszam do lektury.

Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
[2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
[3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
[4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close