User Story jest to skrótowy opis nowej funkcjonalności Produktu lub jego udoskonalenia. Nie zawiera technicznego rozwiązania. Zwykle odpowiada na pytania opisujące funkcjonalność w kategoriach Kto robi?, Co robi? I Dlaczego? User Story opisuje więc działanie Produktu w języku potocznym lub biznesowym. Choć bywa też używana do opisu zadań Scrum Team, które mają na celu poprawę funkcjonowania Zespołu.

User Stories – omówione zagadnienia:

  1. Wprowadzenie
  2. User Story. Czyja to historia?
  3. Jak korzystać z User Stories?
  4. Kryteria akceptacji
  5. Podsumowanie

Wprowadzenie

User Story to najpopularniejszy sposób formułowania zadań realizowanych przez Scrum Team. Pojedyncza User Story określa niewielką funkcjonalność Produktu. Opisuje bowiem najmniejszy sensowny do wyodrębnienia, cząstkowy Cel Produktu. Z tego powodu User Stories są bardzo krótkie.

User Stories są tworzone przez cały czas pracy nad Produktem. Powstają one nieustannie, od momentu podjęcia decyzji o rozpoczęciu pracy, aż po realizację Celu Produktu.

Tworzenie User Stories to zadanie Product Ownera. Na podstawie rozmowy z Klientem formułuje on odpowiedzi na pytania pozwalające stworzyć User Story i wpisuje je do Backlogu Produktu. Jednak User Stories odzwierciedlają nie tylko potrzeby Klienta.

User Story. Czyja to historia?

User Story określa potrzeby użytkownika Produktu tworzonego przez Scrum Team. Dlatego jest wyrażona w języku biznesowym. Innymi słowy, wskazuje na korzyści, jakie jej wprowadzenie przyniesie użytkownikowi produktu. W Backlogu Produktu mogą znaleźć się jednak także User Stories, które dotyczą ,strong>potrzeb Zespołu Developerskiego, na przykład doskonalenia przepływu pracy między Developerami albo opisujące potrzeby Product Ownera, dotyczące na przykład przeprowadzenia prac porządkujących Backlog Produktu. W takich przypadkach Użytkownikiem w User Story staje się odpowiednio Developer i Product Owner.

User Stories można stworzyć odpowiadając na pytania 3W:

  • Kto robi? – Who? (is doing that)
  • Co robi? –What? (are they doing)
  • Po co? Dlaczego? Z jakiego powodu tego potrzebuje? – Why? (do they need it)

User Story zawiera się wtedy w formule:

Jako [typ użytkownika] chcę [co robić?], ponieważ [po co? dlaczego?].

Przykłady User Stories dotyczące funkcjonalności sklepu internetowego zapisane w takiej formie ilustruje poniższa tabelka:

What are User Stories? - table

Formuła ta pozwala nie tylko jasno sformułować User Story. Lecz także w stosunkowo prosty sposób przetłumaczyć język techniczny na język biznesowy i vice versa. Dzięki temu Cel oraz etap pracy nad Produktem jest zrozumiały zarówno dla Developerów, jak i dla Interesariuszy.

Jak tworzyć dobre User Stories używając metody INVEST, opisujemy w osobnym artykule.

Jak korzystać z User Stories?

Stworzenie schematycznej User Story to dopiero początek pracy. Są one bowiem sygnalizatorami, punktami wyjścia do dyskusji nad problemami i ich rozwiązaniem. Dyskusja nad przyjmowanymi do realizacji User Stories ma miejsce podczas Planowania Sprintu. To na ich podstawie do Backlogu Sprintu są wpisywane techniczne zagadnienia rozwiązywane na bieżąco przez Zespół Developerski.

Zwykle w przestrzeni fizycznej User Stories są zapisywane na małych, kolorowych karteczkach przypinanych w miejscu pracy. Natomiast w przestrzeni cyfrowej najlepiej sprawdzają się cyfrowe whiteboardy, współdzielone przez Scrum Team.

Zapisanie w ten sposób User Stories ma kilka zalet, ponieważ:

  • podkreśla autonomię każdej User Story – każda z nich ma osobne ramy i może zostać wykonana niezależnie od innych
  • akcentuje dynamikę User Stories – kolejność ich realizacji jest renegocjowana przez Scrum Team, a aktualny porządek realizacji jest widoczny na tablicy dzięki fizycznemu ułożeniu karteczek z User Stories
  • pełni rolę przypominającą – dzięki wizualnej reprezentacji User Stories Scrum Team ma w zasięgu wzroku drogowskaz, który przypomina o celu podczas tworzenia szczegółowych rozwiązań.

Nakład pracy potrzebny do realizacji danej User Story szacuje Zespół Developerski używając dniówek, roboczogodzin lub Story Points.

Kryteria akceptacji

User Story musi mieć określone kryteria akceptacji już w momencie przyjęcia jej do realizacji przez Zespół Developerski. Kryteria akceptacji determinują, w którym momencie praca nad User Story może zostać uznana za zakończoną.

Dzięki temu zarówno Klient, jak i Developerzy wiedzą, w jaki sposób wykonywana przez nich praca przełoży się na wartość biznesową. Zwykle User Story zostaje uznana za zrealizowaną, gdy określony w niej użytkownik może wykonać opisaną czynność. Korzystając z przykładu powyżej, User Story o treści:

Klient może kupić magiczną różdżkę za pomocą jednego kliknięcia

Zostaje zrealizowana w momencie, gdy na stronie sklepu internetowego pojawia się działający przycisk „Kup teraz”, który wykorzystuje domyślne dane płatności i wysyłki dla zalogowanego użytkownika.

Podsumowanie

User Story jest to zwięzły opis nowej funkcjonalności Produktu lub jego udoskonalenia. Służy on jako najmniejszy Cel wyrażony w języku biznesowym, czyli z perspektywy wartości biznesowej i użytkownika. Pozwala jasno określić zadanie do wykonania, a także określić kryteria jego ukończenia.

Już dziś przeczytaj nasz kolejny artykuł INVEST, czyli jak stworzyć dobre User Story

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 19. Czym są User Stories? 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?