Jeśli trudno Wam w zespole zrozumieć jak działa produkt z punktu widzenia użytkownika, Wasze Epiki i User Stories są dziwnie prozbijane, to warsztat User Story Mapping jest absolutnie tematem dla Ciebie. Powiedzmy sobie jednak szczerze – komu coś takiego nigdy się nie zdarzyło? 😉

Nie ma wtedy sensu szukać winnych i przerzucać się odpowiedzialnością (z jednej story: „user story i epiki były słabo opisane!”, z drugiej strony: „nie przeczytałeś dokładnie user story!”). Reagujmy proaktywnie i minimalizujmy ryzyko braku wspólnego zrozumienia problemu. To właśnie w tym ma pomóc koncept user stories. Metodę user story mapping możesz zaś potraktować jako user stories na resorach.

O samych podstawach nie będę się rozpisywał, gdyż zrobił to już Damian Reweda w poradniku User Story Mapping - mapowanie historyjek użytkownika . Napiszę tylko tyle, że wartość techniki rośnie wprost proporcjonalnie z liczbą niewiadomych w produkcie i jego skomplikowaniu. Im projekt jest bardziej niejasny, tym bardziej opłaca się skorzystać z mapowania historyjek.

Cena kilku godzin całego zespołu jest naprawdę niska wobec znacznego ograniczenia późniejszych problemów komunikacyjnych i frustracji (jak wiemy projekty nie udają się nie dlatego, że ktoś czegoś nie umiał zrobić, a dlatego, że zawiodła komunikacja).

Skupię się natomiast na kilku radach - jak dobrze przeprowadzić warsztat User Story Mappingu z mojego doświadczenia.

• 1. Agenda warsztatu User Story Mapping

• 2. Jak poprowadzić warsztat?

  • 2.1. Organizacja

  • 2.2. Moderacja

  • 2.3. Rozgrzewka

  • 2.4. Rozbudowywanie mapy

  • 2.5. Wykorzystanie

• 3. User Story Mapping zdalnie?

• 4. A co z Event Storming?

• 5. Podsumowanie

1. Agenda warsztatu User Story Mapping

Zacznijmy od agendy, którą najczęściej stosuję na warsztatach (godziny są przykładowe). Taka intensywna, jednodniowa sesja może przebiegać w następujący sposób:

• 9:00 - 9:45 – przedstawienie celu i zasad warsztatu, ćwiczenia rozgrzewkowe

• 9:45 - 10:15 – definiowanie person (ćwiczenie grupowe)

• 10:15 - 10:30 – przerwa

• 10:30 - 12:30 – mapowanie (uczestnicy wspólnie umieszczają post-ity na tablicy, ustalanie flow, grupowanie i porządkowanie)

• 12:30 - 13:30 – przerwa obiadowa (podczas przerwy moderator może dodatkowo uporządkować mapę)

• 13:30 - 15:00 – wstępna wycena post-itów przez zespół programistyczny, product owner dzieli mapę zgodnie z kolejnością wydań

• 15:00 - 15:15 – przerwa

• 15:15 - 16:15 – product owner wraz z zespołem programistycznym wycenia pierwsze wydanie

• 16:15 - 16:30 – podsumowanie

Taka agenda user story mappingu to intensywny, ale niezwykle produktywny dzień. W praktyce przypomina sprint discovery - dużo interakcji, wspólnego myślenia i porządkowania chaosu w głowach zespołu.

Kluczowe jest tu tempo i struktura:

• zaczynasz od wspólnego celu i zbudowania kontekstu,

• potem przechodzisz przez poznanie użytkowników (persony),

• a następnie mapowanie całego doświadczenia krok po kroku.

Przerwy są nieprzypadkowe - to momenty na złapanie dystansu i uporządkowanie mapy (często moderator robi wtedy mały „cleanup” na tablicy).

Popołudnie to już moment decyzji - estymacje, priorytetyzacja i podział na wydania.

Efekt? Zespół kończy dzień z klarownym obrazem produktu, wspólnym językiem i pierwszą wersją roadmapy, która faktycznie ma sens.

2. Jak poprowadzić warsztat? Najważniejsze wskazówki

Przeprowadzenie takiej sesji nie jest szczególnie skomplikowanym zadaniem. Zasady są proste, a forma bardzo angażująca dla uczestników. Jeśli w Twojej firmie nie ma nikogo, kto ma doświadczenie warsztatowe, to jestem przekonany, że sam sobie poradzisz.

Jest jednak kilka rzeczy, o których IMHO warto pamiętać. Poniżej przedstawiam pięć moich doświadczeń, które pomogą przeprowadzić taki warsztat:

2.1. Organizacja

Na spotkaniu na pewno musi być obecny cały zespół programistyczny, designer i product owner (oraz klient w przypadku projektu zewnętrznego). Mile widziani byliby przedstawiciele biznesu (sponsor, marketing, sprzedaż), natomiast na pewno sam dobrze wyczujesz, kogo z Twojej firmy dodatkowo zaangażować. Nie przesadź jednak z liczbą uczestników. Wbrew pozorom im mniej osób zaprosisz, tym większe jednostkowe zaangażowanie uzyskasz (12 osób to moim zdaniem maksimum).

Zadbaj o to, by zespół zarezerwował sobie na warsztat cały dzień. Odpowiednio wcześniej wyślij zaproszenie na spotkanie poprzez kalendarz, aby nikt o nim nie zapomniał i miał na niego przeznaczony czas. Potrzebne jest pełne skupienie. Najlepiej gdyby uczestnicy w tym dniu nie musieli zaglądać do komputerów. Oczywiście laptopy w sali są wykluczone! Może to być brutalne, ale wyniesienie z sali krzeseł również wpłynie pozytywnie na aktywność.

W pewnym momencie warsztatu zorientujesz się, że ciężko zapanować nad post-itami. Dlatego przygotuj karteczki w różnych kolorach oraz kartki w formacie A3 i A4. Bardzo przydaje się również technika poprawnego przyklejania post-itów 😉

2.2. Moderacja

Przyznam, że nie jestem fanem przeprowadzania warsztatów przez lidera projektu (produktowca). Powodem jest tak zwany efekt badacza, kiedy nieświadomie kierujemy dyskusję w kierunku preferowanego przez nas rozwiązania. Poza tym po prostu nie da się zarówno uważnie moderować i myśleć kreatywnie, a czynne zaangażowanie produktowca w mapowanie jest bardzo ważne. Dlatego rekomendowałbym przekazanie odpowiedzialności za przeprowadzanie warsztatu na np. product designera.

Jeżeli jednak uważasz, że jesteś najlepszą osobą do moderacji takiego spotkania, to postaraj się po prostu dać uczestnikom dużo swobody w budowaniu mapy. Pamiętaj jednak, że jako product owner jesteś… no właśnie, ownerem! Ostateczne decyzje jak „przyciąć” i wykorzystać mapę należą absolutnie do Ciebie.

2.3. Rozgrzewka

Jeżeli przeprowadzacie warsztat po raz pierwszy, to poświęć pierwsze 30 minut na ćwiczenia rozgrzewkowe. Wspólnie z zespołem zastosujcie metodę user story mapping do wymodelowania flow typowego poranka. Następnie wymodelujcie go przy scenariuszu, gdy na „zebranie się” macie 15 minut (czy będziesz w obozie konieczności umycia zębów, czy też w opozycji? ;)).

Dzięki rozgrzewce bardzo dobrze zrozumiecie zasady mapowania, a cała grupa przystąpi do docelowego ćwiczenia w dobrych humorach i z pełnym zaangażowaniem.

2.4. „A co z tym?”, czyli rozbudowanie mapy o dodatkowe warunki

„A co z tym?” to podejście rekomendowane przez Jeffa Pattona. Uczestnicy warsztatu analizują poszczególne karteczki, zadając pytania typu „a co jeśli się zepsuje?”, „a co jeśli użytkownik nie poradzi sobie z obsługą”, itd.

Wynikiem jest rozbudowanie mapy o dodatkowe warunki czy przypadki brzegowe, o których mogliście nie pomyśleć (mapowanie ryzyka), a także o wiele dodatkowych, kreatywnych pomysłów.

Skutkiem ubocznym jest znaczny rozrost mapy i późniejsze trudności z jej organizacją. Podczas dalszej pracy należy zatem koncentrować się na głównych składowych flow, a pozostałymi zająć się już poza warsztatem.

2.5. Wykorzystanie

User story mapping to technika, która nie jest zarezerwowana tylko dla dużych projektów. Gdy czujecie, że dane zadanie nie jest do końca jasne, zawsze w kilka minut możecie rozrysować je w formie post-itów według zasady “mapuj tylko to, co jest potrzebne do opowiedzenia historii o funkcji” (Jeff Patton). To technika zwinna. Stosujcie ją więc po prostu kiedy chcecie i jak chcecie.

Jeff Patton radzi, powołując się na koncepcję „grzejnika informacyjnego” (A.Cockburn, Agile Software Development), by efekty pracy zespołu pozostawiać na ścianie. Ma to kilka zalet. Po pierwsze przez kolejne tygodnie działa to na Was inspirująco (pojawiają się nowe pomysły). Po drugie buduje zaciekawienie, a finalnie zrozumienie zadań Waszego zespołu przez resztę organizacji. Po trzecie daje Wam poczucie, że idziecie z pracami według większego planu. Wpływa to bardzo pozytywnie na morale.

3. User Story Mapping zdalnie?

Nie ma żadnych przeszkód by przeprowadzać warsztaty user story mapping zdalnie. Jeśli chodzi o rekomendowane narzędzie, to mogę polecić Miro/Mural.

Trzeba jednak przyznać, że to właśnie kreatywne sesje grupowe tracą najwięcej na braku bezpośredniego kontaktu. Dużą zaletą mapowania historyjek są bowiem dynamiczne interakcje między uczestnikami. Moderator ma też lepsze możliwości wpływu na grupę, a zwłaszcza na mniej zaangażowane lub wycofane osoby.

4. A co z Event Storming?

Metoda user story mapping jest często mylona z event storming. Obie techniki działają w sposób podobny. Różnicą jest to, że:

• User story mapping skoncentrowane jest na zbudowaniu flow aplikacji (odpowiadamy na pytanie „kiedy?”) i mocniej pobudza myślenie kreatywne.

• Event storming jest natomiast metodą, którą poleca się do bardziej szczegółowej analizy i głębszego wchodzenia w problem z perspektywy procesów i funkcji (odpowiadamy na pytanie „co?”).

Warto dodać, że to pierwsze spotkanie dedykowane jest zwłaszcza nowym przedsięwzięciom, natomiast drugie lepiej sprawdza się przy działających procesach.

Można również uogólnić, że user story mapping to technika, z której najwięcej wyciągnie produktowiec i osoby odpowiedzialne ze strategię, zaś event storming to spotkanie na którym prym wiodą analitycy biznesowi i programiści.

Przy rozpoczęciu pracy z nowym produktem dobrą praktyką jest przeprowadzenie warsztatu user story mapping, by dobrze zrozumieć flow, a następnie pogłębienie sesji za pośrednictwem warsztatu event storming. Oczywiście możesz spróbować połączyć oba spotkania lub wybrać tylko jedno. Na zakończenie warsztatu user story mapping możesz poprosić zespół programistyczny o wycenienie post-itów w ramach story pointów, natomiast na warsztacie event storming zajmiecie się ich rozbiciem na mniejsze zadania i dopracowaniem wycen.

5. Podsumowanie

Projekty z reguły nie udają się nie dlatego, że zabrakło umiejętności, a dlatego że zawiodła szeroko pojęta komunikacja. Im dłużej pracuję jako product manager, tym bardziej utwierdzam się w przekonaniu, że to właśnie umiejętności komunikacyjne są kluczowe na tym stanowisku. User story mapping to jedna z najlepszych technik, by zapewnić zrozumienie problemu przez wszystkie zaangażowane osoby. Te warsztaty są nie tylko bardzo pożyteczne, ale i ekscytujące! Warto dać im szansę, a metodę wdrożyć na stałe do naszego trybu pracy.