Story Mapping w praktyce

Zainspirował mnie artykuł, który niedawno ukazał się na naszym blogu, a w którym to Jacek Wieczorek opisuje Story Jam Session jako sposób na szybkie “zasilenie” Product Backlogu wartościowymi User Stories. Pomyślałem sobie, że przecież robiłem razem z Krystianem coś podobnego, tyle że używaliśmy technik User Experience. Postanowiliśmy się z Wami podzielić samym scenariuszem, jak i doświadczeniami związanymi z jego użyciem.

Po raz kolejny wszystko zaczęło się od warsztatów z technik User Expierence, o których możecie poczytać w jednym z wcześniejszych postów. Zdobywając wiedzę o tych technikach borykaliśmy się z problemem braku uchwycenia pewnej ciągłości. Samo zrobienie np. Empathy Map jest oczywiście wartościowe, ale postanowiliśmy zbudować swego rodzaju scenariusz użycia, gdzie kilka technik ”spiętych” ze sobą daje większą wartość, niż użycie tych technik w odseparowaniu od siebie.



Doskonałą okazją stały się odwiedziny w jednym z zagranicznych serwisów, dla którego w tym czasie wraz z zespołem developerskim pracowaliśmy – oderwanie się od codziennych obowiązków, nowe otoczenie, spokój 🙂 – to wszystko mogło nam tylko sprzyjać.

Sam scenariusz opracowaliśmy z myślą o przebudowaniu jednego z procesów w istniejącym już serwisie. Jest to istotne o tyle, że potencjalny scenariusz na stworzenie np. nowego serwisu mógłby wyglądać trochę inaczej. Poniższy scenariusz realizował zespół developerski wraz z Product Ownerem; Ekspert UX (Krystian) był moderatorem warsztatów.

Scenariusz wyglądał następująco:

1. Uzyskanie głębszego poziomu zrozumienia naszego “idealnego użytkownika”- zaczynamy od Empathy Map.

Empathy MapAnalizy dokonujemy z różnych perspektyw, odpowiadając sobie na pytania – co nasz użytkownik: widzi, słyszy, myśli/czuje, mówi, robi w związku z realizacją swojej potrzeby lub użyciem naszego produktu.

Zadanie: Przygotować dwie mapy użytkownika (Empathy Map) serwisu.

Czas: 20 min.

Wynik: Rozrysowane dwie mapy użytkownika

2. Diagnoza problemów w poszczególnych etapach wykorzystania produktu przez użytkownika- User Experience Map

Zespół przygotowuje graficzne odwzorowanie całego procesu, jaki musi przejść użytkownik, aby zrealizować swój cel. Ćwiczenie składa się z dwóch iteracji, przy czym pierwszą iterację można jeszcze podzielić na dwie części: indywidualną i zespołową.

I iteracja

Zadanie: Zespół ma podzielić proces na kroki. Następnie każda osoba samodzielnie przypisuje do każdego kroku:

– pytania – czyli obszary, które wymagają więcej informacji, wyjaśnienia,

– komentarz/ błędy – obszary niedziałające poprawnie, stwarzające problemy,

– idee – pomysły na ulepszenie procesu / danego kroku lub naprawę błędu.

Następnie zespół wspólnie porządkuje tablicę, usuwa duplikaty oraz łączy ze sobą (jeśli to jest możliwe) pytania, komentarze/ błędy z ideami, które je naprawiają, rozwiązują.

Czas: 20 min

Wynik: Tablica z podzielonym na kroki procesem oraz przypisanymi do każdego etapu pytaniami, komentarzami/ błędami, ideami.

II iteracja

Zadanie: Zespół wspólnie wypracowuje idee dla pozostałych pytań, komentarzy/ błędów.

Czas: 20 min.

Wynik: Tablica z podzielonym na kroki procesem, gdzie wszystkie pytania i błędy są zamienione na idee.

3. Dekompozycja idei- Story Mapping

Do tej pory zespół stworzył zbiór idei przyporządkowanych do poszczególnych kroków procesu. Kolejnym etapem będzie zejście na niższy poziom – już bardziej operacyjny (zakres zmian).

Zadanie: Zespół przekształca wszystkie idee na Epiki oraz User Stories, które następnie przenosi na Story Mapping.

Czas: 30 min

Wynik: Story Mapping z rozpisanymi User Stories

4. Priorytetyzacja zakresu zmian- Business Value/ Difficulty Matrix (np Big Wall)

Macierz ułatwia bardzo szybką priorytetyzację zadań w dwóch dowolnych kontekstach. W naszym przypadku kontekstami były złożoność techniczna oraz wartość biznesowa.

Zadanie: Zespół developerski nanosi na osi OX User Stories według trudności realizacji. Product Owner i  interesariusze na osi OY ustawiają User Stories według ważności biznesowej. Macierz zostaje podzielona na 4 obszary:

1 = Target – najważniejsze i najłatwiejsze do wykonania

2 = Strategic – najważniejsze, ale trudne do wykonania

3 = Low-hanging fruit – mało ważne, ale łatwe do wykonania

4 = Luxury – mało ważne i trudne do wykonania

Czas: 10 min

Wynik: Rozmieszczone na macierzy User Stories według trudności realizacji oraz wartości biznesowej

5.  Przeniesienie spiorytetyzowanego zakresu na Story Mapping

Wracamy na Story Mapping ze spriorytetyzowanymi zadaniami, uważając, aby nie “zgubić” priorytetyzacji w trakcie przenoszenia :).

Zadanie: User story zostają przeniesione na Story Mapping według ważności 1,2,3,4. Product Owner zaznacza “linię Mendozy”, czyli zaznacza zadania, które według niego powinny być wykonane w pierwszej kolejności.

Czas: 5 min

Wynik: Wydzielenie z Story Mapping User Stories, które powinny znaleźć się w Backlogu najwyżej.

Podsumowanie

Powyższy scenariusz pokazuje, jak można skutecznie połączyć różne techniki ze świata agile’a oraz User Experience, aby cały zespół mógł szybko zapełnić Product Backlog wartościowymi User Stories. Przez całe UX Story Jam Session zespół był blisko końcowego użytkownika, co ważne jest o tyle, że to przecież dla niego jest tworzony produkt i to jego cele mają być realizowane. Oczywiście, przez cały czas pamiętaliśmy o technicznych i biznesowych aspektach naszego projektu.

Cała sesja charakteryzowała się:

  • wysokim zaangażowaniem całego zespołu,

  • wspólnym opracowaniem końcowego wyniku,

  • maksymalnym ograniczeniem “strat”, jako że wyniki poprzedniego kroku stanowiły materiał wejściowy do kolejnego zadania,

  • szybką priorytetyzacją zadań,

  • stałą obecnością użytkownika.

 A tak wyglądał wynik jednej z przeprowadzonych iteracji:

PS. Zdjęcie nie jest za atrakcyjne, ale za to prawdziwe 🙂

UX Story Jam Session

Artykuł powstał we współpracy z Krystianem Mrozkiem.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x