Jak i po co tworzyć User Stories.

Jak budować User Stories?

User stories to krótki opis cech i właściwości systemu wyrażanych przez potrzebę użytkownika. Wykorzystuje się je w procesach developmentu produktu, w ramach tzw. metodyki Agile (zwinnej) do określenia funkcji i wytwarzanej wartości dla użytkownika. User stories powstają jako efekt współpracy pracy pomiędzy klientem, określającym wymagania i wizję produktu, a zespołem projektowym agregującym i weryfikującym informacje. Taka komunikacja pozwala na uspójnienie wizji, rozwiązań i pożądanego efektu, a także minimalizuje ryzyko powstawania ewentualnych błędów. Najczęściej stosuje się następujący schemat:

• jako – osoba, przypisana rola,
• chcę – cecha, funkcjonalność, czynność,
• ponieważ – uzasadnienie, rezultat, korzyść.

Szukasz software house, który prowdzi projekty używając user stories?
Skontaktuj się z nami.

3 przykłady User Stories:

1. Jako klient sklepu online chcę mieć możliwość zarejestrowania własnego profilu, abym nie musiał za każdym razem uzupełniać danych.
2. Jako użytkownik portalu chcę mieć możliwość ustawienia poziomu dostępu swojego profilu dla osób, których nie znam, aby chronić swoją prywatność.
3. Jako reklamodawca chcę mieć możliwość edytowania budżetu w trakcie trwania kampanii, aby w szybki sposób reagować zmiany.
   

Powyższy schemat pozwala na klarowne określenie: kto, co i dlaczego wykonuje daną czynność, dzięki czemu widzimy nie tylko funkcje, ale również ich wagę i znaczenie dla całego systemu. Konieczność myślenia poprzez pryzmat użyteczności dla użytkownika pozwala odpowiednio zaplanować pracę, uwzględniając biznesowe cele. User stories opisują najczęściej jedną wybraną interakcję użytkownika z systemem.

Pomimo pozornej prostoty bardzo łatwo pominąć komponenty schematu lub źle określić poziom szczegółowości. By temu zapobiec, warto kierować się zasadami tworzenia user stories z poniższego schematu:

• Independent – budowa mini jednostek, które mogą funkcjonować niezależnie od innych i być opracowywane w dowolnej kolejności,

• Negotiable – wypracowane historyjek w zespole drogą dyskusji, rezultat współpracy z klientem,

• Valuable – istotne dla odbiorcy końcowego, ważne dla biznesu,

• Estimable – łatwe do oszacowania w zakresie nakładu pracy,

• Small – na tyle małe, aby łatwo było zaplanować i przeprowadzić iterację, możliwe do wykonania od kilku dni do ok. 2 tygodni,
• Testable – określenie kryteriów akceptacji, zbudowanie scenariuszy testowych i warunków ich przejścia.

Każda historia powinna mieć zdefiniowane kryteria akceptacji, określające: które parametry powinny zostać spełnione, aby historia została zaakceptowana (np. logowanie przez FB, logowanie przez e-mail, logowanie przez LinkedIn, to kryteria akceptacji do funkcji logowania). Sprawdzanie poszczególnych kryteriów w ramach danej historii wyraża się poprzez scenariusz testowy, który określa: co musimy przetestować i jakie funkcje mają działać. Z kolei Definition of done odpowiada na pytanie, jakie parametry świadczą o ukończeniu danej user story. Ukończenie historii odpowiada jednocześnie ukończeniu sprintu.

Przykładowy user story z projektu rozpisanyw JIRA, który realizowaliśmy:

User stories na etapie brainstormingu najczęściej zapisujemy na sticky notes, co ogranicza miejsce i zapewnia większe skupienie na istocie opisywanego działania. Wszystkie historie tworzą zbiór tzw. backlogu i opracowywane są przez team w kolejnych iteracjach w narzędziu JIRA.

Najczęstsze błędy w user stories

Najczęstszymi błędami popełnianymi przy definiowaniu historii użytkowników są:

• zbyt duża szczegółowość – powoduje rozproszenie się zespołu i jego uwagi oraz stwarza ryzyko pominięcia części konwersacji,
• zbyt duża generyczność – stwarza problemy w wyodrębnianiu funkcji w danej iteracji,
• zbyt duża formalność – powoduje brak skupienia na użytkowniku i zmniejsza czytelność opisu,
• użycie technicznych parametrów zamaskowanych w user stories – wypis zadań technicznych, zamiast historii użytkownika przyczynia się do zamazywania priorytetyzacji zadań,
• pomijanie etapu dyskusji – staje się ryzykiem dla utrzymania prawidłowego kierunku rozwoju projektu oraz pominięcia ważnych dla użytkownika funkcji.

Wady i zalety stosowania user stories

Zalety stosowania user stories:

• uspójnienie wizji i języka komunikacji pomiędzy klientem a zespołem,
• priorytetyzacja funkcji,
• maksymalizacja użyteczności dla użytkownika,
• zwiększenie poziomu kreatywności poprzez kooperatywność,
• ułatwienie estymacji czasu poszczególnych iteracji.

Wady stosowania user stories:

• komplikacje w opisie czysto systemowych tasków, np. bugów, spików,
• rozbieżność w zrozumieniu sposobu funkcjonowania danej historyjki pomiędzy klientem a temem developerskim,
• brak informacji dotyczących sposobu wykonania i interfejsu designu – różnice pomiędzy poszczególnymi deweloperami,
• skupienie się na funkcjonalnościach biznesowych i pominięcie technicznych np. wydajność serwera,
• utrata kontroli nad całokształtem wizji wynikająca z fragmentaryzacji funkcjonalności.

Estymacja czasowa iteracji odbywa się za pomocą nadania Story Points, które określają tzw. rozmiar relatywny, odnoszący relację historyjek względem siebie. Punkty nie określają bezwzględnej jednostki w czasie. Oznacza to, że wybierając najprostsze zadanie, przypisując mu wartość równą 2, zakładamy, że zadanie z opisem 4 zajmie nam dwukrotnie więcej czasu od pierwszego. Punkty odzwierciedlają rozmiar pracy, a nie czas potrzebny do jej wykonania. Dzięki temu różnice wynikające z zasobów, umiejętności czy podejścia przestają stanowić punkt rozbieżny. To samo zadanie wykonywane jest przez dwa różne zespoły w różnym tempie, dlatego uwzględniać należy rozmiar pracy oraz wydajność zespołu.

Dobrze napisane user story przyczynia się do ustrukturyzowania pracy w zespole i zaoszczędzania czasu przy wdrażaniu pomysłu. Historie użytkownika pozwalają wykorzystać efekt synergii wynikający ze wspólnego wypracowywania najlepszych możliwych efektów. Dlatego ta metodologia, nazywana zwinną, jest stosowana na co dzień w firmach wytwarzających software.

Potrzebujesz estymacji projektu? Skontaktuj się z nami.