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

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

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

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

Konfirmacja

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.

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

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?