Backlog ma kilkaset pozycji. Wszystko opisane i posortowane po priorytecie, planowanie sprintu idzie sprawnie. I wtedy na refinemencie pada proste pytanie: co właściwie użytkownik przechodzi od wejścia do aplikacji do umówionej wizyty? Robi się cicho. Zespół zna pojedyncze historyjki na pamięć, ale nikt nie potrafi opowiedzieć całej drogi. Płaski backlog tej drogi po prostu nie pokazuje.
Lista w Jirze przypomina listę zakupów. Mówi, co trzeba kupić, ale nie mówi, jakie danie z tego wyjdzie. Możesz mieć sto pozycji ułożonych od najważniejszej i nadal nie wiedzieć, czy po zrobieniu górnych dwudziestu ktokolwiek przejdzie przez produkt od początku do końca. Story mapping powstał po to, żeby ten obraz odzyskać. Da się go zbudować na jednej ścianie, w jedno popołudnie.
Mapa historyjek, czyli backlog w dwóch wymiarach
Metodę opisał Jeff Patton w książce "User Story Mapping" i to jego wersja jest dla mnie punktem odniesienia. Pomysł jest prosty. Zamiast układać historyjki w jednej kolumnie, rozkładasz je na płaszczyźnie. Poziomo biegnie podróż użytkownika: od pierwszego kontaktu z produktem do momentu, w którym dostaje swój efekt. Pionowo rośnie poziom szczegółu: im niżej, tym drobniejsze historyjki i tym mniej pilne warianty tego samego kroku.
Ta zmiana geometrii ma praktyczne skutki. Lista odpowiada na jedno pytanie: co jest najważniejsze. Mapa dokłada drugie: w którym miejscu podróży to siedzi. Patrzysz na listę i widzisz ranking. Patrzysz na mapę i widzisz opowieść, a w opowieści od razu słychać, czego brakuje. Jeśli w podróży użytkownika nie ma całego etapu, lista ci tego nie powie, bo nieistniejącej pozycji nie da się wypatrzeć w rankingu. Na mapie zostaje pusta kolumna i ta pustka sama się o siebie upomina.
Szkielet mapy: aktywności, kroki, historyjki
Mapa ma trzy poziomy. Na górze backbone, czyli kręgosłup: duże aktywności użytkownika, nazwane jego językiem. Pod każdą aktywnością kroki, które użytkownik wykonuje w jej ramach. Dopiero pod krokami historyjki, czyli kawałki funkcjonalności na tyle małe, że można je wziąć do sprintu.
Pokażę to na systemie rezerwacji wizyt u specjalistów. Kręgosłup mógłby brzmieć tak: znalezienie specjalisty, wybór terminu, rezerwacja, przygotowanie do wizyty, zmiana lub odwołanie. Pięć aktywności, czytanych od lewej do prawej jak zdania w opowiadaniu. A pod spodem, dla kilku z nich:
Znalezienie specjalisty
- Krok: przeglądanie listy specjalistów
- pacjent widzi listę z nazwiskami i specjalizacjami
- pacjent filtruje listę po specjalizacji
- pacjent czyta opinie innych pacjentów
- Krok: sprawdzenie profilu
- pacjent widzi opis doświadczenia i cennik
- pacjent ogląda zdjęcia gabinetu
Wybór terminu
- Krok: przeglądanie kalendarza
- pacjent widzi wolne terminy na najbliższy tydzień
- pacjent przełącza widok na cały miesiąc
- Krok: dopasowanie terminu do własnego grafiku
- pacjent filtruje terminy po porze dnia
- pacjent porównuje kalendarze dwóch specjalistów obok siebie
Rezerwacja
- Krok: podanie danych
- pacjent rezerwuje wizytę bez zakładania konta
- pacjent zakłada konto, żeby nie wpisywać danych ponownie
- Krok: płatność
- pacjent płaci online z góry
- pacjent wybiera płatność na miejscu
- Krok: potwierdzenie
- pacjent dostaje potwierdzenie mailem
- pacjent dostaje przypomnienie SMS dzień przed wizytą
Zmiana lub odwołanie
- Krok: odwołanie wizyty
- pacjent odwołuje wizytę linkiem z maila
- pacjent przenosi wizytę na inny termin bez dzwonienia
Zwróć uwagę na dwie rzeczy. Po pierwsze, w każdej kolumnie historyjki są ułożone od najprostszej wersji do coraz bogatszych: lista z nazwiskami wystarczy, żeby ktoś znalazł specjalistę, opinie to już wygoda. Po drugie, każda karteczka jest napisana z perspektywy pacjenta, nie systemu. "Pacjent widzi wolne terminy", a nie "endpoint zwraca dostępność". O tym, jak pisać pojedyncze historyjki i jak ciąć je na mniejsze, napisałem w osobnym wpisie - tutaj wystarczy zasada, że jedna karteczka opisuje jedną rzecz, którą użytkownik może zrobić.
Warsztat: półtorej godziny przy ścianie
Mapy nie buduje się samemu przy biurku. Jej wartość bierze się z tego, że powstaje wspólnie, więc zacznij od składu. Potrzebujesz kogoś od biznesu, kto zna cel produktu i klienta, do tego product ownera i przynajmniej jednego dewelopera, bo on najszybciej wyłapie, gdzie mapa rozjeżdża się z techniczną rzeczywistością. Jeśli masz w firmie osobę, która na co dzień rozmawia z użytkownikami, na przykład z obsługi klienta, zaproś ją koniecznie. Analityk prowadzi całość jako facylitator: pilnuje procesu i zadaje pytania, a własne pomysły zostawia na końcu kolejki. Sześć, góra siedem osób. Powyżej tego warsztat zamienia się w teatr z widownią.
Materiały są banalne. Na miejscu: ściana albo duże okno, karteczki samoprzylepne w dwóch kolorach (jeden na aktywności i kroki, drugi na historyjki) i gruby marker dla każdego, żeby napisy było widać z drugiego końca sali. Zdalnie: Miro albo dowolna tablica online - mechanika jest ta sama, tylko pilnuj, żeby wszyscy naprawdę dokładali karteczki, a nie patrzyli, jak robi to jedna osoba.
Sam przebieg planuję zwykle na jakieś 90 minut:
- Rama (10 minut). Ustalacie, kim jest użytkownik i z czym przychodzi, a do tego gdzie podróż się zaczyna i gdzie kończy. Bez tej ramy mapa rozłazi się na boki.
- Kręgosłup (20 minut). Każdy pisze na karteczkach duże aktywności, potem wspólnie układacie je od lewej do prawej i sklejacie duplikaty. Spory o kolejność są tu wartością, nie przeszkodą, bo ujawniają, że każdy miał w głowie trochę inny produkt.
- Kroki i historyjki (30 minut). Schodzicie poziom niżej i wypełniacie kolumny. Facylitator pilnuje wysokości lotu: jeśli ktoś wrzuca szczegół implementacji, karteczka wraca do autora.
- Spacer po mapie (15 minut). Jedna osoba opowiada na głos całą podróż od lewej do prawej. To najtańszy test kompletności, jaki znam, bo dziury słychać w opowieści szybciej, niż widać je na ścianie.
- Pierwsza linia wydania (15 minut). O tym za chwilę, bo zasługuje na własny rozdział.
Na jednym z pierwszych warsztatów, jakie prowadziłem, osoba z obsługi klienta podeszła w trakcie do ściany i dołożyła karteczkę: "pacjent nie przyszedł na wizytę". Nikt z zespołu produktowego o tym scenariuszu nie pomyślał, a dla niej to był chleb powszedni rozmów telefonicznych. W płaskim backlogu ta luka mogłaby siedzieć miesiącami. Na ścianie znalazła się po kwadransie.
Efektem warsztatu jest wspólny obraz produktu w głowach uczestników. Zapisana ściana to dopiero drugi rezultat - ważny, ale wtórny wobec tego, że kilka osób po raz pierwszy zobaczyło ten sam produkt.
Cięcie wydań: linia pozioma przez całą mapę
Teraz część, dla której warto było wstać od biurka. Bierzesz taśmę albo sznurek i prowadzisz poziomą linię przez całą mapę. Wszystko nad linią wchodzi do pierwszego wydania. Zasada jest jedna i twarda: linia musi przeciąć każdą kolumnę. Pierwsze wydanie to najcieńszy możliwy przejazd przez całą podróż użytkownika, a nie najlepiej oceniona górna warstwa backlogu.
Dla naszego systemu rezerwacji mogłoby to wyglądać tak: lista specjalistów bez filtrów, kalendarz z wolnymi terminami w widoku tygodnia, rezerwacja bez zakładania konta, potwierdzenie mailem i odwołanie wizyty linkiem z tego maila. Bez płatności online, bez opinii, SMS-y też poczekają. Surowe? Bardzo. Ale pacjent przechodzi całą drogę od szukania do odwołania i produkt od pierwszego dnia robi to, po co istnieje.
Porównaj to z podejściem "bierzemy górne dwadzieścia pozycji z listy". Przy odrobinie pecha dostajesz dopracowany kalendarz z filtrami i porównywarką terminów oraz produkt, w którym nie da się odwołać wizyty. Każda pozycja z osobna była ważna, całość nie działa. Tak rozumiane pierwsze wydanie to w praktyce MVP - osobno opisałem, czym jest MVP i jak ciąć zakres bez utraty wartości. A klasyczna priorytetyzacja wymagań metodami MoSCoW i WSJF wciąż się przydaje, tyle że wewnątrz pasma między liniami: do układania kolejności prac, nie do decydowania o kształcie wydania.
Co zrobić z mapą po warsztacie
Zdjęcie ściany to za mało. Mapa, która zostaje tylko na fotografii w czyimś telefonie, umiera w tydzień. Przenieś ją do narzędzia: tablica online jako żywy dokument, a struktura do Jiry, na przykład aktywności kręgosłupa jako epiki i historyjki podpięte pod nie. Zadbaj, żeby powiązanie działało w obie strony. Patrzysz na epik i wiesz, w którym miejscu podróży jesteś. Patrzysz na mapę i wiesz, co z niej już trafiło do sprintów. O codziennej pracy z samą listą napisałem więcej we wpisie o prowadzeniu backlogu.
Mapa żyje tak długo, jak długo ktoś do niej wraca. Dobry rytm to powrót przy planowaniu każdego kolejnego wydania i przy większych zmianach zakresu. Jest też prosty test na co dzień: jeśli nowa historyjka nie ma oczywistego miejsca na mapie, to albo mapa się zestarzała, albo historyjka nie służy żadnemu krokowi użytkownika. Obie odpowiedzi są warte poznania.
Mapa umiera wtedy, gdy przestaje być źródłem prawdy: w Jirze zakres dawno się zmienił, a na tablicy wisi wersja z warsztatu. Martwa mapa bywa gorsza niż żadna, bo daje złudzenie wspólnego obrazu, którego już nie ma.
Kiedy story mapping nie zadziała
Mapa historyjek zakłada, że istnieje podróż użytkownika: ktoś przychodzi z potrzebą i po kilku krokach wychodzi z efektem. Nie każdy system tak wygląda. Integracja między dwoma systemami, przetwarzanie wsadowe, migracja danych czy czyste API nie mają bohatera, który idzie przez opowieść, więc mapa wychodzi sztuczna. Jeśli czujesz, że wciskasz produkt w narrację na siłę, to sygnał, że narzędzie nie pasuje do problemu. A kiedy prawdziwym wyzwaniem jest zrozumienie złożonej domeny, a nie utrata obrazu całości, lepiej sprawdzi się warsztat event stormingowy poprowadzony krok po kroku.
Story mapping leczy jeden konkretny ból: masz produkt, przez który użytkownik przechodzi od potrzeby do efektu, a backlog rozsypał ci ten przebieg na konfetti. Jeśli to twój przypadek, zarezerwuj salę z dużą ścianą i przetestuj mapę przy najbliższym planowaniu. Ryzykujesz półtorej godziny i plik karteczek.
Jeśli przy okazji chcesz sprawdzić, jak radzisz sobie z samymi historyjkami i kryteriami akceptacji, przygotowałem darmowy test z user stories i kryteriów akceptacji. Rozwiążesz go bez zakładania konta, a wynik zobaczysz od razu.
Najczęstsze pytania
Ile trwa warsztat story mappingu?
Około półtorej godziny na pierwszą mapę produktu: dziesięć minut na ramę, dwadzieścia na kręgosłup, pół godziny na kroki i historyjki, kwadrans na spacer po mapie i kwadrans na wyznaczenie pierwszego wydania. Dłuższe sesje rzadko dokładają obraz, a zaczynają dokładać szczegóły, które i tak zmienią się przy pierwszym kontakcie z użytkownikiem.
Kogo zaprosić na warsztat story mappingu?
Kogoś od biznesu, kto zna cel produktu, product ownera, przynajmniej jednego dewelopera i, jeśli w firmie taka osoba jest, kogoś, kto na co dzień rozmawia z użytkownikami. Sześć osób, góra siedem, bo powyżej tego warsztat zamienia się w teatr z widownią. Analityk prowadzi jako facylitator i własne pomysły zostawia na koniec kolejki.
Czym mapa historyjek różni się od backlogu w Jirze?
Backlog jest listą i porządkuje pracę według ważności. Mapa dokłada drugi wymiar, czyli miejsce kroku w podróży użytkownika, więc widać na niej nie tylko kolejność, ale i brakujące etapy. Lista nie potrafi pokazać czegoś, czego na niej nie ma; na mapie zostaje po tym pusta kolumna.
Co zrobić z mapą po warsztacie?
Przenieś ją do narzędzia, w którym zespół pracuje na co dzień, i zepnij oba kierunki: z zadania ma dać się dojść do miejsca w podróży użytkownika, a z mapy do prac, które już poszły do sprintów. Zdjęcie ściany w czyimś telefonie nie spełnia tego warunku. Jeśli po dwóch sprintach nikt do mapy nie zajrzał, problemem nie jest narzędzie, tylko to, że zespół nie planuje wydaniami.