Jak pisać User Stories, aby każdy je zrozumiał

User Story jest jednym z elementów procesu rozwoju niemal każdego produktu IT z wykorzystaniem metodologii Agile. Służy jako podstawa do opracowania dodatkowej logiki biznesowej, funkcjonalności i projektu. Błędy podczas tworzenia historii użytkownika mogą prowadzić do tego, że produkt końcowy nie spełni oczekiwań użytkownika. Więcej o tym, czym są User Stories i jak je poprawnie komponować, opowiemy w artykule.

Czym są User Stories i dlaczego są naprawdę potrzebne

W swej istocie historia użytkownika jest nieformalnym sposobem budowania komunikacji między użytkownikami lub interesariuszami biznesowymi i programistami. Co prawda nie jest to element absolutnie niezbędny, jednak niemal zawsze wykorzystywany jest w sytuacjach, gdzie konieczne jest zrozumienie i pokazanie interakcji użytkownika z produktem IT.

Zazwyczaj historie użytkowników są pisane przy użyciu następujących dwóch szablonów:

1. As a <user/user role> I want <capability> so that <benefits description>. Czego ja, jako użytkownik, chcę lub muszę uzyskać z systemu (czyli funkcjonalność), aby rozwiązać swoje problemy/obsługiwać własne potrzeby.

1. In order to <receive benefit> as a <role>, I can <goal/desire>. Aby uzyskać pożądaną wartość w konkretnej roli, określamy co użytkownik musi uzyskać od produktu pod względem funkcjonalności.

Zasadniczą różnicą pomiędzy szablonami jest to, na czym się skupiamy – w drugim jesteśmy nakierowani na konkretną wartość, której zdefiniowanie jest w zasadzie jednym z głównych zadań analityka biznesowego. Oczywiście napisanie jednego takiego wyrażenia nie wystarczy, aby stworzyć pełnoprawne zadanie dla programistów – trzeba opisać więcej szczegółów, aby określić jasne wymagania dotyczące stworzenia jakiejś części produktu. Pomaga w tym określona struktura konstruowania User Story i jej oceny według określonych kryteriów jakości.

Podstawowe kryteria jakości historii użytkownika

Istnieją różne podejścia do oceny jakości historii użytkownika. W praktyce formuła INVEST jest często stosowana ze względu na jej prostotę i uniwersalność.

INVEST:

• Independent — User Story powinna być integralna i niezależna od innych komponentów, ale uwzględniać możliwe interakcje pomiędzy różnymi komponentami systemu. Przykładowo początkujący BA często popełniają błąd oddzielając UI od Backendu – musimy pamiętać, że oddzielnie od siebie nie mają one sensu dla użytkowników.
• Negotiable — User Story powinna być powodem do dyskusji i poszukiwania rozwiązań, w jaki sposób najlepiej wykonać zadanie i zaspokoić potrzeby użytkownika.
• Valuable — Każda historia użytkownika musi zapewniać wartość.
• Estimable — Wysokiej jakości historię użytkownika zawsze można obliczyć w story points, godzinach itp.
• Small — Dobrze, jeśli dużą User Story można podzielić na mniejsze (zdekomponować), aby każdy z nich lepiej się rozwijał i miał większą elastyczność w planowaniu procesu rozwoju.
• Testable — Pisząc historię trzeba liczyć się z możliwością jej przetestowania.

User Stories muszą spełniać wszystkie kryteria z listy INVEST. Jeśli tak nie jest, należy to uzupełnić lub zmienić, ponieważ źle napisana historia może powodować problemy na przyszłych etapach rozwoju.

Przykład nieprawidłowej User Story

Wyobraź sobie opracowanie projektu medycznego. BA, po skontaktowaniu się z zainteresowanymi stronami, przedstawia następującą przykładową historię użytkownika: As a user I want to see patient data from system HC-1 in system CHC-12 so that I can use the data. 

Zastanówmy się wspólnie, co jest nie tak w tej historii użytkownika:

• nie ma wyjaśnienia, który user: lekarz, pacjent, administrator itp.;
• patient data mogą różnić się formatem i objętością;
• capabilities bez jasnego sformułowania, bo dane można tworzyć, edytować, usuwać, więc nie wystarczy wskazać to see patient data;
• benefits zależą od roli użytkownika, jego działań i innych czynników.

Oznacza to, że w tej przykładowej historii użytkownika wyraźnie nie ma wystarczającej liczby szczegółów, aby stworzyć jasną specyfikację techniczną dla programistów. Konieczne jest rozbicie historii użytkowników na osobne historie, biorąc pod uwagę role użytkowników i inne kwestie.

Przykład dobrej User Story

To jest User Story do wyświetlenia listy produktów w sklepie internetowym, zgodnie z opisem zadań w Jira. Jest napisana według jasnej i zrozumiałej struktury, zawiera niezbędne szczegóły: kim jest użytkownik, co chce uzyskać, jak ma wyświetlić się lista produktów i dlaczego.

Dekompozycja User Stories

Dekompozycja User Story to podział dużej historii na mniejsze, tak aby każda miała swoją wartość dla użytkownika i spełniała inne kryteria jakościowe. Ma to na celu określenie zakresu zadań dla programistów i uproszczenie planowania – małe zadania znacznie łatwiej zmieścić w jednym sprincie niż duże zadanie. Jako przykład rozważmy stronę logowania do witryny.

Jest jedno duże zadanie – opracować Login Page. Aby zoptymalizować proces, rozkładamy go na sześć oddzielnych User Stories, w jaki sposób dana osoba może się zalogować. Każda historia jest niezależna od pozostałych i ma swoją wartość, a niektóre z nich w razie potrzeby można dodatkowo podzielić – zaimplementuj tę samą walidację dla numeru 5 lub dodaj kilka etapów dla sytuacji przypomnienia hasła.

Jak przeprowadzić dekompozycję

Tak naprawdę dekompozycja każdego projektu obejmuje podzielenie Systemu na Epics – duże fragmenty funkcjonalności, których nie da się wdrożyć w jednym sprincie. Dlatego też następuje dalszy podział na mniejsze części – User Stories. Te z kolei podzielone są na Tasks – to właśnie nimi zajmują się programiści i testerzy.

Oczywiście schemat może być bardziej skomplikowany, np. pomiędzy Systemem a Epic będzie Novel. Należy jednak pamiętać, że tak czy inaczej, jeden użytkownik historii zawsze należy do tylko jednego Epicu. Kiedy wszystkie Tasks konkretnej historii użytkownika zostaną zakończone, zostaje ona zamknięta. Dzieje się tak ze wszystkimi blokami, aż do ukończenia wszystkich Epics – wtedy możemy powiedzieć, że System jest zbudowany.

W Jira proces dekompozycji wygląda następująco:

W tym przypadku System = Backlog, następuje podział na mniejsze bloki. Ciekawostką jest możliwość dodania modułów pośrednich:

• Spike — zadanie, które zespół musi wykonać przed ukończeniem User Story. Na przykład, aby napisać moduł, musisz dodatkowo przestudiować nową technologię.
• Enable / Tech Story — wyzwanie techniczne, które odblokowuje w ogóle możliwość rozpoczęcia User Story.

Moduły te są potrzebne, aby uprościć planowanie i zarządzanie procesem rozwoju jako całością.

Podstawowe podejścia do dekompozycji

User Story Mapping

Story Map — prosta i popularna technika tworzenia Backlogu, wykorzystująca metodę dekompozycji wizualizacji zwaną by workflow step.

1. W aplikacji określasz głównych Users i ich cele – User Goals: kupić coś, napisać recenzję itp.
2. Główne działania użytkownika opisujesz w oddzielnych blokach Activity.
3. Działania użytkownika rozkładasz na kroki Steps, które muszą wykonać, aby wykonać określoną czynność, np. kupić produkt: zalogować się, wybrać, dodać do koszyka, kupić.
4. Podziel kroki na osobne User Tasks według priorytetu – te ważniejsze, czyli funkcjonalność obowiązkowa i podstawowa, znajdują się wyżej.

Proces User Story Mapping jest wygodny, ponieważ możesz stworzyć Story Map samodzielnie, wspólnie z klientem lub zespołem. Jednocześnie uzyskany wynik jest przejrzysty, a wszystkie dane można łatwo wprowadzić do dowolnego menedżera zadań, takiego jak Jira.

Zamiast wniosku

Prawidłowo stworzona User Story znacznie upraszcza planowanie i rozwój produktu. Pomaga zrozumieć kontekst zadania, a przy pomocy właściwej dekompozycji można uwzględnić jak najwięcej szczegółów i znacznie zmniejszyć ryzyko błędów. Najważniejszą rzeczą do zapamiętania jest to, że dobra historia użytkownika ma przejrzystą strukturę i spełnia podstawowe kryteria jakości: Independent, Negotiable, Valuable, Estimable, Small, Testable.