Review Flashcards
Jakie pytania warto zadać gdy “zapominamy o slajdach?”
Co chcieliśmy osiągnąć?
Jaki był kierunek?
Jak działają funkcjonalności?
Jak idą historyjki?
Co daje zespołowi review?
Poczucie spełnienia celu
Jakie ma być review?
Ma to być hands-on, by klient pobawił się z tym i miał nowe pomysły, które przybliżą nas do celu/dodadzą wartości
Jaka powinna być prezentacja?
Krótka
Klarowna - tylko to co ma znaczenie
Kusząca (pokazuje czym sie produkt/funkcjonalność różni od konkurencji, odpowiada na pytanie “i co z tego?”)
Skondensowana - nie mów dłuże o czymś niż 15 sek
Konkretna - jak pomoże rozwiązać problem
Jaki jest cel sprint review? I co tam sie dzieje?
Inspekcja efektów pracy wykonanej w trakcie sprintu i wskazanie przyszłych zmian. Prezentujemy kluczowym interesariuszom i określamy postęp ku osiągnięciu celu produktu.
Co robimy po prezce?
Interesariusze i scrum team ocenia efekty pracy w sprincie i ustalają co należy zrobić w dalszej kolejności
Proponowana agenda (w labieryncie jest dokładniejsza)
- Check-in (określenie celu i oczekiwań względem spotkania)
- Sprint goal + overview - czy udało się osiągnąć cel? co się udało skończyć co nie? jakie były problemy i jak rozwiązane? Czy są jakieś przeszkody?
- Demo - prowadzące do:
- Discussion - o tym co zaprezentowane, zebranie pomysłów na przyszłość, feedbacku
- Adapt - Zespół z interesariuszami omawia co będzie robione w następnej kolejności. Warto zadać pytania: Czy stakeholderom podoba się to co widzą? Czy chcą zobaczyć zmiany? Czy brakuje ważnego featura? Czy jest overdeveloping nad czymś?
6 dobrych praktyk na product review
- Zaproś właściwych interesariuszy
- Przygotuj się do review całym zespołem
- Wizualizuj spotkanie
- Angażuj interesariuszy w spotkanie (i feedback)
- Eksperymentuj z formą
- Zawsze pokazuj przyrost
Interesariusze nie uczestniczą w spotkaniu (identyfikacja, konsekwencje, porady)
Identyfikacja:
Interesariusze nie uczestniczą w spotkaniu
Konsekwencje:
brak feedbacku
brak innych pkt widzenia
Interesariusze nie znają postępów -> mogą chcieć w trakcie sprintu oderwać deweloperów od pracy by zrobić spotkanie statusowe
Spotkanie z PO to sztuka dla sztuki
Porady:
Zaprosić osobiście/mail -> upewniść się że to nie koliduje z innym spotkaniem, że pamiętają dzień przed
Pogadać z interesariuszami jaką wartość daje ich obecność na spotkaniu
Sesja demo (identyfikacja, konsekwencje, porady)
Identyfikacja: Review to tylko sesja demo, nie ma dyskusji Konsekwencje: Brak feedbacku Brak dyskusji co do planów/wizji/scenariuszy i priorytetów Brak inspekcji i adaptacji Porady: Spytać interesariuszy o feedback Przygotować agendę Zbudować prezkę w którą każdy ma wkład
Brak wartości dla użytkownika (identyfikacja, konsekwencje, porady)
Identyfikacja:
Zespół prezentuje aspekty techniczne, bez wartości dla użytkownika
Zespół mocno używa słownictwa technicznego
Konsekwencje:
Zespół skupia się na aspektach technicznych
Ciężko określić postęp z perspektywy użytkownej
Porady:
Dobrze przygotowany product backlog (invest)
Spytać interesariuszy: jak oceniają wartość tego co zobaczyli z perspektywy użytkownika
Umówić się z zespołem że prezentujemy z punktu widzenia użytkownika
Brak planu spotkania (identyfikacja, konsekwencje, porady)
Identyfikacja:
Chaos na spotkaniu
Zespół ma trudności w płynnej prezentacji nowych funkcjonalności
Konsekwencje:
Stresujące wydarzenie więc zespół może chcieć zrezygnować
Interesariusze niezadowoleni
Wszyscy tracą czas
Porady:
Przeprowadź dzień przed testowe product review
Odwiedź review w innym zespole by się zainspirować
Przechodzić od ogółu do szczegółu, by interesariusze mogli wyjść gdy za dużo szczegółów
PO prowadzi product review (identyfikacja, konsekwencje, porady)
Identyfikacja:
PO prowadzi review, zespół jest bierny nie bierze udziału
Konsekwencje:
Odpowiedzialność za efekty przesuwa się na PO
Zespół traci okazje do myślenia produktowego
Spada motywacja
Porady:
Zaangażować cały zespół: za każdym razem kto inny prezentuje (każdy aktualizuje wiedze o wszystkim w produkcie); każdy mówi o tym nad czym pracował
