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ć.

Najczęstsze błędy popełniane przy pisaniu User Story – omówione zagadnienia:

  1. Wprowadzenie
  2. Problemy z 3W
  3. Problemy z 3C
  4. Podsumowanie

Wprowadzenie

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 User Story 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 User Story.

Problemy z 3W

Właściwie napisana User Story odpowiada na pytania:

  • Who? (Kto?)
  • What? (Co?)
  • Why? (Dlaczego?)

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?.

Who? i persona użytkownika

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 User Story na mniejsze fragmenty, żeby nie wykonywać sprzecznych, wykluczających się, albo po prostu nieskutecznych działań.

Why? czyli źle określony cel

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 realizacji User Story. Przykładem błędu, gdzie miejsce celu zajmuje opis dodatkowej funkcjonalności daje taka User Story:

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.

Problemy z 3C

Praca z User Stories jest często dzielona na trzy etapy nazywane 3C:

  • Card – Karta – na której zapisywana jest User Story
  • Conversation – Konwersacja – rozmowa wewnątrz Scrum Team na temat karty User Story
  • Confirmation – Konfirmacja – czyli określenie kryteriów akceptacji potwierdzających wykonanie zadania

Na każdym z nich mogą pojawić się błędy, które opisujemy poniżej.

Karta

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ą User Story. 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.

Konwersacja

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. User Story jest raczej zaproszeniem do rozpoczęcia konwersacji dotyczącej konkretnych rozwiązań technicznych, które z kolei doprowadzą do realizacji biznesowej wartości określonej przez User Story.

Konfirmacja

O kryteriach akceptacji, jakie muszą zostać określone dla każdej User Story pisaliśmy szczegółowo w tekście opisującym, czym jest User Story [link]. 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.

User Story mistakes

Podsumowanie

Przygotowując i korzystając z User Stories warto trzymać się przede wszystkim zasad:

  • Precyzyjnego określenia użytkownika, którego dotyczy zmiana
  • Jasnego określenia celu budowania nowej funkcjonalności produktu
  • Małej objętości User Story
  • Traktowania User Story jako punktu wyjścia do rozmowy na temat rozwiązań z Zespołem Developerskim
  • Określenia jasnych zasad akceptacji

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.

Scrum Guide | 21. Najczęstsze błędy popełniane przy pisaniu User Story caroline becker avatar 1background

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ść.