User Stories - co to jest i jak z nich korzystać?

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.

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:

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.

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

Zobacz wszystkie posty