Spotkanie przeglądowe Sprintu jest ograniczone czasowo do 4 godzin.
- Zespół nie powinien spędzać więcej niż 1 godzinę na przygotowaniach do przeglądu Sprintu.
- Celem przeglądu Sprintu jest zaprezentowanie przez Zespół Właścicielowi Produktu i interesariuszom funkcjonalności, która jest ukończona. Chociaż znaczenie „ukończone” może się różnić w zależności od organizacji, zazwyczaj oznacza to, że funkcjonalność jest całkowicie zaprojektowana i może być potencjalnie wdrożona lub dostarczona. Jeśli „ukończone” ma inne
znaczenie, upewnij się, że Właściciel Produktu i interesariusze to rozumieją. - Funkcjonalność, która nie jest „ukończona”, nie może być prezentowana.
- Artefakty, które nie są funkcjonalnością, nie mogą być prezentowane, chyba że są używane w celu wsparcia zrozumienia demonstrowanej funkcjonalności.
Artefakty nie mogą być pokazywane jako produkty pracy, a ich użycie musi być zminimalizowane, aby uniknąć dezorientacji interesariuszy lub wymagania od nich zrozumienia, jak działa rozwój systemów. - Funkcjonalność powinna być prezentowana na stanowiskach pracy członków Zespołu i uruchamiana z serwera najbliższego produkcji — zwykle serwera środowiska zapewnienia jakości (QA).
- Przegląd Sprintu zaczyna się od prezentacji celu Sprintu przez członka Zespołu, zobowiązanego do realizacji elementów z Product Backlog oraz zakończonych elementów z Product Backlog. Różni członkowie Zespołu mogą następnie omówić, co poszło dobrze, a co nie poszło dobrze w Sprint.
- Większość przeglądu Sprintu spędza się na prezentacji funkcjonalności przez członków Zespołu, odpowiadając na pytania interesariuszy dotyczące prezentacji oraz notując pożądane zmiany.
- Na koniec prezentacji interesariusze są ankietowani, jeden po drugim, aby uzyskać ich wrażenia, wszelkie pożądane zmiany oraz priorytet tych zmian.
- Właściciel Produktu omawia z interesariuszami i Zespołem potencjalne przearanżowanie Product Backlog na podstawie otrzymanych opinii.
- Interesariusze mają prawo zgłaszać wszelkie uwagi, obserwacje lub krytyki dotyczące przyrostu potencjalnie dostarczalnej funkcjonalności produktu między prezentacjami.
- Interesariusze mogą zidentyfikować funkcjonalność, która nie została dostarczona lub nie została dostarczona zgodnie z oczekiwaniami i poprosić o umieszczenie takiej funkcjonalności w Product Backlog w celu priorytetyzacji.
- Interesariusze mogą zidentyfikować wszelką nową funkcjonalność, która przychodzi im do głowy podczas oglądania prezentacji i poprosić o dodanie tej funkcjonalności do Product Backlog w celu priorytetyzacji.
Artykuły o wydarzeniach Scrum
- Czym jest planowanie Sprintu?
- Czym jest przegląd Sprintu?
- Czym jest spotkanie retrospektywne Sprintu w Scrum?
- Czym jest doskonalenie Product Backlog?
- Czym jest ciągła integracja / dostarczanie / wdrażanie w Scrum?
- Czym są wydarzenia ograniczone czasowo w Scrum?
- Czym jest Spike w Scrum?
- Czym jest Planning Poker w Agile?
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文