Sprint Review to nie demo!

“It’s the feedback cycle that tends to really make development go fast” — Jeff Sutherland

Sprint Review czy demo? A co za różnica? W wielu organizacjach spotykam się, z tym, że Sprint Review nazywany jest demo. Często wynika to, z tego, że ludzie nie widzą różnicy pomiędzy tymi dwoma określeniami. Czy na pewno nie widzisz różnicy pomiędzy Przegląd Sprintu a demo?

Nawet, kiedy Zespoły Scrumowe mają w ostatni dzień Sprintu zaplanowanie Sprint Review, to i tak zapytani o to, co się dzieje podczas tego spotkania mówią, że trzeba zrobić demo.

Kolejne pytania pozostają już bez odpowiedzi. Po co to demo? Dla kogo? Można się dowiedzieć, że Sprint Review to ten moment kiedy Product Owner ogląda co zrobił Zespół Developerski i odbiera Sprint. To bardzo ciekawy pomysł. A co jeśli odrzuci Sprint?
Czy Sprint może się nie udać? Zostawmy odpowiedź na to pytanie na kolejnego posta.

Można też spotkać się z tym, że Przegląd Sprintu to takie miłe spotkanie, na którym wszyscy klaszczą a na koniec wjeżdża pizza, a przynajmniej dają ciastka :-)

Jeśli skupimy się tylko na pokazaniu demo, czyli tego co nam poszło dobrze w Sprincie, czy to wywoła dyskusje, wątpliwości? Czy nastąpi tutaj pętla sprawdź i dostosuj (inspect & adapt)? No i najważniejsze pytanie czy cel Sprint Review zostanie osiągnięty?

Mam nadzieję, że moje wyjaśnienie poniżej rozwieje wszelkie wątpliwości i pozwoli zrozumieć, że słowa mają znaczenie.

Po co w Scrum mamy Sprint Review?

Przyjrzyjmy się zagadnieniu od samego początku. Jaki cel do osiągnięcia kryje się za Sprint Review? Zajrzyjmy do Scrum Guide.

„Przegląd Sprintu to spotkanie organizowane na zakończenie Sprintu w celu przeprowadzenia inspekcji Przyrostu i, jeśli zajdzie taka potrzeba, dostosowania Backlogu Produktu. Podczas Przeglądu Sprintu Zespół Scrumowy i interesariusze współpracują w zakresie tego, co zostało ukończone w Sprincie. Na tej podstawie oraz na podstawie zmian wprowadzonych do Backlogu Produktu w trakcie Sprintu, uczestnicy spotkania wspólnie rozważają, co mogłoby być wykonane w następnej kolejności, aby zwiększyć dostarczaną wartość.”

Zobacz co o Sprint Review mówi Jeff Sutherland, współtwórca Scrum.

Przez cały Sprint chroniliśmy Zespół Developerski przed wpływami z zewnątrz i zmianami zakresu Sprintu. Product Owner był jedynym stykiem ze światem zewnętrznym. Sprint Review to jest ten moment, kiedy osobom spoza Zespołu Scrum mówimy, chodź i zobacz co zrobiliśmy. Oczywiście kiedy pokazujemy kolejny Przyrost Produktu zadajemy pytanie “I co o tym sądzisz?”. Przecież, tym ma się różnić Agile Software Development od waterfall, że dostarczamy mniejsze funkcjonalności i często pytamy o feedback.

Interesariusze powinni powiedzieć nam jak odbierają kolejną wersję, którą zbudował Zespół Developerski, przedyskutować co jest potrzebne w kolejnych Sprintach. Interesariusze często przynoszą również informacje, które mogą wpłynąć na kształt Produktu i pracę Zespołu. Możemy tutaj dowiedzieć się rzeczy, które bezpośrednio wpłyną na wygląd Product Backlog. Czy to Product Owner zmieni kolejność na Product Backlog, czy edytujemy Product Backlog Item. Dostosowanie następuje właśnie teraz. Sprawdzamy Przyrost Produktu i dostosowujemy Product Backlog — Inspect & Adapt.

Co się dzieje podczas Sprint Review?

Pierwszym krokiem jest przedstawienie przez Product Ownera jaki był cel Sprintu i co faktycznie udało się osiągnąć a czego nie.
Zespół deweloperski omawia jak przebiegała praca w Sprincie, jakie problemy napotkał podczas Sprintu i jak zostały rozwiązane. Jeśli nadal mamy nierozwiązane impedimenty, to dobrze, żeby Interesariusze byli tego świadomi.
Sama demonstracja, bez wnikliwej dyskusji nie daje żadnej wartości i może dawać fałszywy obraz, ponieważ skupiamy się tylko na tej części pracy, która się powiodła a nie na Celu, który faktycznie był do osiągnięcia w Sprincie.

Dopiero po tych krokach następuje część, w której Zespół Deweloperski pokazuje demo – czyli działający Przyrost Produktu, który jest ukończony. To czy prezentować także nieukończone funkcjonalności, to inna dyskusja. Demonstracja produktu to tylko pretekst do wywołania dyskusji na temat tego, co właśnie zbudowaliśmy, nowych pomysłach i ewentualnych zmianach, które chcielibyśmy wprowadzić w przyszłości. Na tej podstawie Zespół Scrum razem z interesariuszami omawia co budować w dalszej kolejności i jak. Dzięki czemu Przegląd Sprintu dostarcza wartościowego wkładu na Planowanie Sprintu.

Podczas Przeglądu Sprintu powinna paść też jasna odpowiedź na pytanie “Jak nam idzie?”. Czyli Product Owner powinien pokazać aktualną roadmapę, plany wydań, pokazać jak ten Sprint wpłynął na datę lub zakres kolejnego wydania. Jeśli Product Owner podjął decyzję o wdrożeniu na produkcję, to teraz jest właściwy moment, żeby poinformować Interesariuszy kiedy mogą spodziewać się nowej wersji.

Podsumowanie

Podsumowując, najważniejszym elementem Sprint Review jest dogłębna dyskusja i współpraca pomiędzy Scrum Team a Interesariuszami.

Demo Przyrostu jest istotne w kontekście wywołania dyskusji, ale jest to tylko jeden z kroków Sprint Review i sam w sobie nie przynosi wartości. Tak więc jeśli nazywasz Sprint Review demo, sugeruję przestać.

Fundamentalnym celem Sprint Review jest sprawdzenie i dostosowanie Backlogu Produktu poprzez zebranie feedbacku i informacji w dyskusji z interesariuszami.