Story Mapa to dopiero początek, coś jak spis treści. Co można zrobić dalej:

  • przypisać wysokopoziomowe estymacje (np. w trakcie sesji planning pokera), aby sprawdzić czy zakres, który wybraliśmy do danej wersji jest możliwy do osiągnięcia w założonym czasie. Estymacje opracowujemy tylko w ramach jednej wersji, gdyż zawartość kolejnych może się jeszcze zmienić.
  • opracowujemy rozwiązania – metody realizacji poszczególnych historyjek, wspólnie z całym zespołemśledzimy na bieżąco postępy na mapie. Oznaczamy już dostarczone elementy, a gdy planujemy kolejny sprint, to mapa w czytelny sposób podpowiada czym warto się zająć w kolejnych krokach.
  • przed zakończeniem bieżącej wersji przygotowujemy zakres kolejnej, uwzględniając aktualne wyniki, ograniczenia, zależności itp.

Mam już mapę i co dalej?

13 Maja - po-spotkaniowo

Tak jak powyżej – według nas User Story Mapa to dopiero wstęp do opracowywania rozwiązań technicznych. Taka “surowa” mapa po warsztacie zdecydowanie nie wystarcza do rozpoczęcia developmentu. Konieczne jest opracowanie na przykład:

  • szczegółowego opisu – detali każdej z historyjek, 
  • ustalenie kryteriów akceptacji 
  • dodanie szkiców ekranów
  • podanie przykładowych danych, konkretnych przypadków zastosowania w praktyce.

Jaki poziom szczegółowości mapy /historyjek wystarczy aby ruszyć z developmentem?

Hi-levelowa estymacja.

Hi-levelowa estymacja, aby przed rozpoczęciem podać jakieś widełki czasowe – ile sprintów potrzeba na realizację uzgodnionego zakresu (tutaj zagadnienie nieco odchodzi od samej mapy ale dla mnie jest ciekawe, gdyż ja osobiście posługuję się tutaj stożkiem niepewności)

W tym celu stosujemy estymacje relatywne – każdą z historyjek szacujemy w Story Pointach w relacji do innych. Następnie określamy szacowaną prędkość zespołu. Na przykład na podstawie danych historycznych, lub analizując szczegółowo zakres pierwszego sprintu, a potem przeliczając to wstecz na Story Pointy. Taka wartość jest ciągle aktualizowana – po każdym sprincie należy zaktualizować średnią prędkość i sprawdzić oczekiwaną datę dostarczenia. Artur przedstawił to w szczegółach w kursie dostępnym na Udemy.

 

Jeżeli zespół to jak go zachęcić? (zauważam, że na kontraktach pracują różni ludzie, spora część to osoby robiące tylko tickety i nic więcej, ja oczekiwałbym czegoś więcej aby produkt ostatecznie miał szanse powodzenia)

 

Interesujące pytanie. Według nas optymalnie jest jak każdy z zespołu czuje odpowiedzialność za produkt. Wiemy jednak, że to często jest utopia. User Story Mapping pomaga mocno w budowaniu takiego zaangażowania. Zamiast zwyczajnie przydzielać tickety, to:

  • zapraszasz do kreatywnego generowania rozwiązań 
  • opowiadasz historię – problem do rozwiązania
  • szybko dostarczasz działający produkt – coś, co znacząco podnosi satysfakcję

Odpowiedzialność za produkt - czy tylko PO/Analityk czy również zespół?

Czy traktować te zagadnienia jako takie pseudo sub-taski pod dużą historyjką biznesową?

Czy wrzucać je na mapę jako rozwinięcie tej historyjki biznesowej?

 

W naszej praktyce nie dodawaliśmy technicznych tasków do mapy. Traktujemy ją jako opowieść o użytkownikach i ich wyzwaniach, a nie o realizacji. 

Od strony trakowania i późniejszego prowadzenia projektu, dodajemy takie elementy jako np. Taski (żeby rozróżnić od User Story) i przydzielamy im estymację. Ponieważ ciężko porównywać estymacje relatywne historyjek biznesowych i tasków technicznych, to preferujemy estymowanie Tasków w godzinach/dniach i ewentualne przeliczanie ich “wstecz” na podstawie wartości średnich na Story Pointy, aby uwzględnić je w kalkulacjach velocity.

Jak na mapie traktować zagadnienia techniczne?

W pracy nad story mapą skupiamy się na zmapowaniu historii użytkowników. Jeżeli zrozumiemy w pełni potrzeby i oczekiwania, to potem w trakcie części “technicznej” dużo łatwiej jest podzielić zakres na moduły domenowe. Z tego względu User Story Mapping wpasowuje się w Domain Driven Design – jest świetnym wstępem do zrozumienia domeny biznesowej. 

Czy User story Mapa powinna być budowana z punktu widzenia komponentów domenowych (modułów), czy historii użytkownika?

Podobnie jak z innymi technicznymi zadaniami – na mapę nie nanosimy detali typu format komunikacji, potwierdzenia, szyfrowanie itp. Integracja od strony biznesowej powinna się tam jednak znaleźć. Przyklejamy więc karteczkę typu: “Przesłanie danych do Salesforce” itp. Możemy też ustalić jakiś symbol, lub dodatkową karteczkę, która wyraźnie wskazuje, że z danego punktu “wychodzimy” na zewnątrz.

Integracja z systemem zewnętrznym > co z technicznymi elementami związanymi z integracją (główny cel > podanie high - level estymaty)?

Jeżeli różni użytkownicy, czyli różniące się mocno od siebie persony, wykonują podobne akcje (np. wydruk tego samego dokumentu) w osobnych krokach, to dodajemy te czynności jako osobne karteczki (User Story). Możemy je jakoś oznaczyć, np. poprzez taki sam symbol. Chodzi o to, że użytkownik X może mieć zupełnie inne zrozumienie systemu i będzie potrzebował więcej wyjaśnień i wsparcia UX, lub może być w innym momencie procesu i przyda się dodatkowe objaśnienie do czego służy dana funkcjonalność akurat w tym momencie. Jeżeli jednak te czynności i użytkownicy są niemalże identyczni, to zostawiamy jedną karteczkę i na niej wpisujemy miejsca w procesie, gdzie taka funkcjonalność się powtarza.

Co zrobić jeśli mamy różne formy dystrybucji dla tego samego zadania i /lub inne persony?

Jeżeli POC jest wyłącznie techniczne, to nie umieszczamy go na mapie. Jeżeli jednak jest to część procesu czyli coś, co może być później wykorzystane w implementacji, to według nas powinno to się znaleźć na mapie. Można wtedy użyć innego koloru karteczek, lub przedstawić POC jako pierwszą wersję – oddzielając te historyjki wyraźnie poziomą linią.

Czy POC brać pod uwagę w mapie jako część całości (też POC) czy tylko mapujemy finalny system z punktu widzenia funkcjonalności?

+48 523 68 98