Oficjalne zatwierdzanie pracy podczas Sprint Review – Tak czy Nie?

Niektóre zespoły używają Sprint Review jako okazji do oficjalnego zatwierdzenia ukończonych w danym Sprincie elementów Product Backlogu przez Product Ownera lub kluczowych interesariuszy.

Zasadniczo Sprint Review nie powinien być używany przez zespół do uzyskiwania odbioru pracy od Product Ownera. Zespół i Product Owner powinni przez cały Sprint tak ściśle ze sobą współpracować, aby zespół i tak wiedział, co Product Owner sądzi o jego pracy.

„Żadnych niespodzianek" to moja zasada nr 1 dla Sprint Review

Całkowicie akceptowalne jest, gdy Product Owner nie przyjmuje pracy zespołu dla danego elementu Product Backlogu. Jednak zespół powinien wiedzieć o tym z wyprzedzeniem.

Członkowie zespołu nie powinni wchodzić na Sprint Review i oczekiwać dużego uznania za swoją pracę, by potem zupełnie nieoczekiwanie zebrać same skargi.

Czy Sprint Review może być oficjalnie używany do odbioru pracy?

Jeśli klient zleca dostawcy stworzenie produktu, idealnie byłoby, gdyby ktoś w firmie klienta pełnił rolę Product Ownera. W takim przypadku może być w porządku, że funkcje są zatwierdzane na Sprint Review. Mimo to nadal twierdzę, że na Sprint Review nie powinno być żadnych niespodzianek.

Nawet jeśli Product Owner ze strony klienta przekazuje zespołowi informacje zwrotne podczas Sprintu, możliwe jest, że będzie musiał poczekać z oficjalnym zatwierdzeniem, aż inni interesariusze będą mieli okazję wypowiedzieć się na temat pracy.

Prosty przykład

Prosty przykład: Moja córka zapytała mnie niedawno, czy może wziąć udział w wycieczce szkolnej. Powiedziałem, że nie mam nic przeciwko, ale – zgadnij – musielibyśmy jeszcze zapytać jej mamę. Powodem było to, że moja żona mogła już mieć inne plany dla rodziny na ten czas, o których jeszcze nie wiedziałem.

A odbiór w prawdziwym projekcie?

To codzienna sytuacja dla Product Ownerów przy zleceniach deweloperskich. Nawet jeśli Product Ownerowi, który codziennie współdziała z zespołem, podoba się to, jak dana funkcja została zbudowana, może mimo to musieć upewnić się, że interesariusze, których reprezentuje, również podzielają tę opinię. Oczywiście można by powiedzieć, że Product Owner mógłby po prostu do nich pójść i zapytać. Ale może to być bardzo niepraktyczne i dlatego najlepiej zrobić to po prostu na Sprint Review.

W przypadku takich zleceń deweloperskich klient nie zawsze zapewnia Product Ownera. Często klient płaci za to, żeby partner umowny zajął się wszystkim.

Oczywiście klient jest nadal właściwym Product Ownerem. Klient ostatecznie zaakceptuje lub odrzuci pracę deweloperską. Ale nie chce być „nękany" tymi sprawami na co dzień. Rozwiązaniem jest wtedy zazwyczaj to, że dostawca wystawia Product Ownera z własnej firmy.

I w takim przypadku żadne elementy Product Backlogu nie mogą zostać zaakceptowane ani odebrane przed Sprint Review. Właściwy Product Owner (z firmy klienta) nie jest wystarczająco dostępny i zaangażowany, żeby móc częściej cokolwiek odbierać.

Oczywiście zespół może uzyskać wstępną zgodę od swojego Product Ownera podczas Sprintu. Jednak prawdziwy Product Owner z firmy klienta może na Sprint Review ostatecznie podjąć zupełnie inną decyzję.

Ostateczna odpowiedź zależy, jak często, od kontekstu danej sytuacji. I dlatego muszę powiedzieć, że nie przejmuję się zbytnio, gdy oficjalny odbiór prac odbywa się na Sprint Review. Mimo to nadal twierdzę, że na Sprint Review nie powinno być żadnych niespodzianek. Rób to, co jest dla Ciebie najbardziej odpowiednie. Najważniejsze, żeby członkowie zespołu wiedzieli przed Review, co ich czeka.

Ten tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.

Sprint Planning zorientowane na velocity

=> Zalety i wady Sprint Planningu zorientowanego na velocity

Kiedy należy zmieniać kolejność elementów?

=> Oto 5 dobrych powodów, dla których należy od czasu do czasu zmieniać kolejność elementów w Sprincie.