User Stories opisują działanie nowej funkcjonalności Produktu w języku potocznym lub biznesowym. Jednak ich przygotowanie nie jest takie proste, jak mogłoby się wydawać. W dzisiejszym wpisie wskazujemy najczęściej pojawiające się problemy oraz podpowiadamy, jak sobie z nimi poradzić.
User Story może być naprawdę świetnym narzędziem motywującym Zespół do proponowania nowych rozwiązań problemów przedstawionych z perspektywy użytkownika. O tym, czym jest pisaliśmy w osobnym wpisie. Natomiast w tym artykule przybliżyliśmy INVEST, czyli popularną metodę pisania dobrych User Stories. Dzisiaj skupimy się na tym, co może pójść nie tak podczas pisania i korzystania z tego narzędzia..
Właściwie napisana User Story odpowiada na pytania:
Jednak odpowiedzi na każde z tych pytań mogą towarzyszyć problemy. Najrzadziej pojawiającym się problemem są wątpliwości dotyczące tego, co powinno zmienić się w produkcie w odpowiedzi na potrzeby Klienta. Dlatego skoncentrujemy się na problemach dotyczących Who? i Why?.
Jednym z najczęstszych błędów popełnianych przy tworzeniu User Stories jest brak wystarczająco precyzyjnej odpowiedzi na pytanie: dla kogo? Innymi słowy, kto jest użytkownikiem, dla którego przeznaczona jest planowana zmiana?
Często nie wystarczy ogólna odpowiedź wskazująca na Klienta czy też End Usera jako adresata zmiany. Rozwiązaniem tego problemu jest wyobrażenie sobie odbiorcy jako konkretnej persony. Persona jest to modelowe wyobrażenie docelowego Klienta. Innymi słowy, persona to reprezentacja osoby, która będzie korzystać z Produktu w określony sposób.
Po analizie User Story może okazać się, że opowiada ona historie różnych person równocześnie. Jeśli docelowych użytkowników jest wielu, warto zastanowić się nad rozbiciem ich na mniejsze fragmenty, żeby nie wykonywać sprzecznych, wykluczających się, albo po prostu nieskutecznych działań.
Zdarza się, że źródłem problemów staje się ostatnia sekcja User Story. Powinna ona określać biznesową wartość, jaką wnosi zmiana dokonywana podczas jej realizacji. Przykładem błędu, gdzie miejsce celu zajmuje opis dodatkowej funkcjonalności może być:
Jako Klient chcę kupić magiczną różdżkę za pomocą jednego kliknięcia, ponieważ chcę w przyszłym tygodniu kupić latający dywan.
Powód kupienia magicznej różdżki zostaje tutaj zastąpiony dodaniem kolejnego punktu do listy zakupów potencjalnego Klienta. Dlatego przygotowując User Story warto pamiętać o powodach, dla jakich potrzebna jest nowa lub zmieniona funkcjonalność Produktu.
Praca z User Stories jest często dzielona na trzy etapy nazywane 3C:
Na każdym z nich mogą pojawić się błędy, które opisujemy poniżej.
Karta, na jakiej zapisana jest User Story ma ograniczoną pojemność. Dlatego najczęściej pojawiającymi się problemami są kłopoty z długością i objętością stories. Z założenia powinna być ona zwięzła i naprawdę zamykać się w jednym, konkretnym zdaniu.
Problem karty User Story ma bowiem dwa wymiary. Jeden to sposób jej sformułowania, który musi być zwięzły i zawierać minimalną ilość wyliczeń. Drugi to rzeczywista objętość User Story. Jednym ogólnym zdaniem można bowiem wyrazić ogromną ilość zadań, które nie mogą zostać zrealizowane w trakcie jednego Sprintu.
Jednozdaniowe sformułowanie User Story stanowi punkt wyjścia do rozmowy z Zespołem Developerskim. Dlatego błędem jest traktowanie jej jako opisu zadania do wykonania. Zamyka to bowiem możliwości negocjacji i dyskusję nad różnymi możliwościami jej realizacji. User Story nie powinna być traktowana jak opis wymagań dotyczących nowej funkcjonalności produktu. Jest raczej zaproszeniem do rozpoczęcia konwersacji dotyczącej konkretnych rozwiązań technicznych, które z kolei doprowadzą do realizacji biznesowej wartości.
O kryteriach akceptacji, jakie muszą zostać określone dla każdej User Story pisaliśmy szczegółowo w innym tekście. Jednym z często popełnianych błędów jest jednak brak lub niejasność kryteriów wykonania zadania.
W przypadku dobrze napisanej User Story, ona sama zawiera opis sytuacji, w której zostaje zrealizowana. Jej sprawdzianem jest to, że użytkownik jest w stanie skorzystać z nowej funkcjonalności stworzonej przez Zespół Developerski.
Przydatnym narzędziem do sprawdzenia poprawności User Strory jest ,strong>opracowanie testu akceptacyjnego. Zwykle zostaje on zapisany po drugiej stronie karty zawierającej User Story.
Przygotowując i korzystając z User Stories warto trzymać się przede wszystkim zasad:
O używaniu User Stories można powiedzieć to samo, co o stosowaniu Scruma. Są bardzo łatwe w teorii, natomiast trudne do zastosowania w praktyce. Tworzenie dobrych User Stories wymaga treningu i doświadczenia. Warto także pamiętać, że nie są one jedyną dostępną formą zapisywania zadań w Backlogu Produktu.
Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.
Produktywność jest w ostatnim czasie szczególnie często poruszanym zagadnieniem. Powodem takiego stanu rzeczy jest fakt,…
Specjaliści od zarządzania zasobami ludzkimi są odpowiedzialni za szereg ważnych decyzji. Wybór odpowiedniego kandydata przyczyni…
Wraz z ukształtowaniem się nowych pokoleń, zmianom ulega również środowisko i kultura pracy. Generacja Y,…
Badania przeprowadzone przez firmę Owl Labs wskazują, że już 16% organizacji pracuje w trybie zdalnym,…
Wykorzystanie sztucznej inteligencji sprawia, że możemy komunikować się z naszymi urządzeniami używając języka naturalnego –…
“Zamknij okno!” wypowiedziane do asystenta AI będzie oznaczać co innego, gdy pracujemy w edytorze tekstu,…