Story Jam Session – czyli Product Backlog od zera w jeden dzień

Wyobraźmy sobie, że mamy pomysł na nowy produkt lub zestaw nowych funkcji w istniejącym produkcie. Problem, z którym spotykają się zespoły, to szukanie odpowiedzi na pytanie, w jaki sposób zamienić dosyć rozmytą zazwyczaj wizję produktu na gotowy, oszacowany Product Backlog, z którego już podczas kolejnego Sprintu Product Owner będzie mógł wskazać pierwsze elementy do realizacji.

W tego typu sytuacjach dobrze sprawdza się technika „Story Jam Session”. Warto zarezerwować na jej przeprowadzenie cały dzień, tak aby nie zabrakło czasu na żaden z jej elementów składowych. Pomocne dla osób biorących udział w tym wydarzeniu może być przeprowadzenie go poza firmą, aby móc skupić się wyłącznie na tym konkretnym zadaniu, z dala od biura i codziennych obowiązków.

Oto jak wygląda jej przebieg:

Przed sesją

0. Rozpoznanie interesariuszy

Warto zastanowić się, kto jest zainteresowany stworzeniem produktu. Na spotkaniu tym powinni pojawić się wszyscy, których produkt ten bezpośrednio dotyczy. Co ważne, jeśli użytkownika końcowego produktu zazwyczaj reprezentuje grupa ludzi lub konkretna osoba, warto, aby użytkownik taki pojawił się osobiście. Informacje na temat produktu z pierwszej ręki, od osoby która na co dzień z niego korzysta, okazują się zazwyczaj bezcenne.

Właściwa sesja

1. Otwarcie sesji

Celem tego ćwiczenia jest ustalenie podstawowych zasad, obowiązujących podczas sesji. Zazwyczaj na takiej liście pojawiają się punkty dotyczące sposobu zabierania głosu w dyskusji („w jednej chwili mówi jedna osoba”) czy korzystania z urządzeń elektronicznych („nie używamy telefonów komórkowych”). Pomocne może być wybranie moderatora, który zapewni sprawne przeprowadzenie sesji w zadanych ograniczeniach czasowych.

2. Przekazanie wizji produktu

Celem tego ćwiczenia jest przekazanie wizji produktu wszystkim zainteresowanym. Product Owner wraz z interesariuszami przekazuje swoje wyobrażenie produktu, mając na uwadze poniższe aspekty:

  • Dla kogo tworzymy produkt?
  • Jaki problem rozwiązujemy?
  • Jakie są potrzeby odbiorcy?
  • Jaką wartość chcemy przekazać?
  • Co chcemy osiągnąć?
  • Dlaczego to jest istotne?

3. Sesja pytań oraz odpowiedzi

Celem tego ćwiczenia jest uzyskanie wspólnego rozumienia produktu pośród uczestników sesji. Jest to moment, kiedy zespół zadaje dodatkowe pytania, aby lepiej zrozumieć wizję produktu. Rozmowa ta może zająć trochę czasu – ważne, aby w wyniku jej przeprowadzenia zespół „poczuł” produkt, który będą budować.

4. Identyfikacja użytkowników produktu

Celem tego ćwiczenia jest identyfikacja kluczowych użytkowników produktu. Zanim zespół przygotuje User Stories, warto poświęcić czas, aby zastanowić się, ilu jest użytkowników docelowego produktu. Ról powiązanych z produktem może być kilka – np. użytkownik zalogowany, użytkownik nie zalogowany, VIP czy administrator. Każdy z tych użytkowników ma inne potrzeby, które najprawdopodobniej będą realizowane oddzielnymi User Stories w Product Backlogu. Wypracowaną listę użytkowników warto zapisać w widocznym miejscu, tak aby podczas tworzenia User Stories zespół miał do tej listy łatwy dostęp.

5. Tworzenie User Stories

Celem tego ćwiczenia jest przygotowanie jak największej liczby User Stories. Wszyscy członkowie Zespołu Scrumowego (indywidualnie – w ciszy), rozpoczynają wypisywanie na małych kartkach User Stories, które ich zdaniem są konieczne, aby zrealizować produkt zgodnie z wcześniej przedstawioną wizją. Wszystkie kartki zbierane są w jednym miejscu, przykładowo na środku stołu lub wrzucane są do wcześniej przygotowanego pojemnika. Indywidualna praca uczestników pozwala na przełożenie ich rozumienia wizji na User Stories, nie sugerując się pomysłami innych osób, czy też hamując swoje pomysły, obawiając się krytyki ze strony współuczestników.

6. Omówienie oraz scalenie przygotowanych User Stories

Celem tego ćwiczenia jest ujednolicenie User Stories, tak aby otrzymać jedną, spójną listę. Aby tego dokonać, jedna osoba – może to być Product Owner – czyta każdą User Story i poddaje ją dyskusji z zespołem oraz interesariuszami, aby ostatecznie uwzględnić ją (lub nie) w tworzonym Product Backlogu. Podczas tego ćwiczenia część User Stories może zostać usunięta, mogą także pojawić się nowe, a największe z nich mogą w razie konieczności zostać poddane dekompozycji.

7. Szybka estymacja

Celem tego ćwiczenia jest szybkie wyestymowanie utworzonych User Stories, przy pomocy techniki Magic Estimation. Pomimo, iż precyzja takiego estymowania nie jest tak duża, jak w przypadku użycia techniki Planning Poker, to jest wystarczająca na tym etapie pracy. Jest to bowiem wyłącznie pierwsze urealnienie oczekiwań Product Ownera oraz interesariuszy w kontekście czasu, jaki jest potrzebny, aby zamienić utworzone User Stories w gotowy produkt.

8. Ustalenie priorytetów

Celem tego ćwiczenia jest ustalenie priorytetów rozwoju produktu – szukamy odpowiedzi na pytanie, które User Stories wykonamy w pierwszej kolejności, a które mają dla nas marginalne znaczenie. Jest to moment, kiedy interesariusze zestawiają ze sobą wartość dostarczaną przez konkretne User Stories do ich złożoności. Może się okazać, że istnieją User Stories, które dostarczają duża wartość dla użytkownika końcowego, a dodatkowo są proste w realizacji – takie User Stories wykonujemy w pierwszej kolejności, aby już od pierwszych Sprintów maksymalizować wartość produktu. Z drugiej strony, znajdą się User Stories, których wartość jest wątpliwa, a dodatkowo są trudne w realizacji – takie User Stories będą wykonane w dalszej kolejności.

9. Zamknięcie sesji

Celem tego ćwiczenia jest podsumowanie efektów przeprowadzenia sesji oraz dokonanie jej oceny, pod kątem przyszłych usprawnień. W tym kontekście warto ocenić przygotowanie do sesji (czy czegoś brakowało?), dobór interesariuszy (czy wszystkie kluczowe osoby były obecne?) oraz czas przeznaczony na poszczególne etapy sesji (czy czasu było wystarczająco?). Przydatną techniką pomocną w ocenie sesji może być Happiness Door.

Podsumowanie

Jak widać z przebiegu sesji, duży nacisk położony jest na bliską współpracę wszystkich osób zaangażowanych w stworzenie produktu. Warto pamiętać o tym także po zakończeniu Story Jam Session. Dobrym przykładem na wzmacnianie zespołowości może być wspólna praca całego zespołu, związana z przeniesieniem User Stories przygotowanych w trakcie sesji do docelowego Product Backlogu, tak aby cały ciężar tej operacji nie spadł wyłącznie na Product Ownera.

Dodaj komentarz

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

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x