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:
- Jako klient sklepu online chcę mieć możliwość zarejestrowania własnego profilu, abym nie musiał za każdym razem uzupełniać danych.
- 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ść.
- 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.
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.
