Jak pisać zwięzłe i jasne user stories?

W dzisiejszym świecie, w którym biznes i technologia rozwijają się bardzo dynamicznie, zrozumienie potrzeb użytkowników jest bardzo ważne. Dostawcy przygotowują dla nich interfejsy i oferują produkty w formie, o której często klienci sami decydują. Dlatego wiele zespołów projektowych, działających w metodyce agile, korzysta z user story. To sposób zapisu wybranej funkcjonalności z perspektywy użytkownika końcowego, zawierający najważniejsze informacje o wartościach, których poszukuje klient. W poniższym artykule omówię, jak powinno wyglądać user story i dlaczego warto je stosować. 

User story (pol. historyjka użytkownika) powinno być pisane z perspektywy osoby, która będzie korzystała z danej funkcjonalności. Opis powinien zawierać tylko najważniejsze informacje. Choć słowo „story” sugeruje, że chodzi o zapis długiej historii, to powinna być ona zapisana krótko i zwięźle – najlepiej w jednym zdaniu. Stąd właśnie w polskim tłumaczeniu, pojawia się frywolnie brzmiąca „historyjka”. Tradycyjnie user story zapisywano na małych karteczkach (np. samoprzylepnych), lub kartonikach. W ten sposób trzymano się zasady dotyczącej zwięzłości treści

Aby łatwiej było zapamiętać, w jaki sposób pisać user stories, powstał szablon i skrót 3W, który doskonale opisuje, co powinno być w nim zawarte: 

Jako (Kto?) chcę wykonać (Co?), aby (Dlaczego?). 

• Kto? (ang. Who) – informacja o użytkowniku i tym, jakim typem jest. 
• Co? (ang. What) – opis zadania do wykonania przez użytkownika.
• Dlaczego? (ang. Why) – oczekiwany przez usera wynik zadania. 

Przykład: 

Jako klient sklepu internetowego chcę zapisać na swoim koncie numer karty debetowej, aby wygodnie dokonywać płatności przy kolejnych zakupach.

Ten prosty sposób tworzenia user stories pomaga lepiej zrozumieć, w jaki sposób stworzyć lub zmodyfikować daną funkcjonalność, aby użytkownik otrzymał wymagany efekt. Dla zwiększenia dokładności historyjek powstała także metoda wspierająca ich tworzenie, podobna do SMART dla wyznaczania celów projektów. Dlatego po stworzeniu user story warto sprawdzić, czy pokrywa się ona z techniką INVEST:

• Istniejąca samodzielnie (ang. Independent) – niezależna od pozostałych historyjek stworzonych w ramach danego projektu. 
• Negocjowalna (ang. Negotiable) – napisana w taki sposób, aby umożliwić negocjację pomiędzy Project Ownerem a zespołem deweloperów. 
• Wartościowa (ang. Valuable) – powinna nieść ze sobą wartość dla końcowego użytkownika, a nie dla zespołu pracującego nad daną funkcjonalnością. 
• Estymowalna (ang. Estimable) – określenie czasu, w którym powinno zająć wdrożenie historyjki w życie.
• Mała (ang. Small) – wykonalna w trakcie jednego sprintu i łatwa w implementacji. 
• Testowalna (ang. Testable) – możliwa do przetestowania. 

Dobre user story powinno posiadać trzy ważne elementy, zgodne z wprowadzoną przez Rona Jeffriesa koncepcją CCC. 

• Karta (ang. Card) – określenie dla user story. W tym miejscu możemy zapisać historyjkę zgodnie z wcześniejszym szablonem jej tworzenia, czyli 3W. Może ona stanowić swego rodzaju tytuł, który będzie ją wyróżniał spośród innych. 
• Konwersacja (ang. Conversation) – rozmowa pomiędzy członkami zespołu projektowego, oparta o historyjkę użytkownika. To moment na doprecyzowanie detali i umieszczenie ich w user story, tak, aby prawidłowo zaimplementować daną funkcjonalność. 

Konfirmacja (ang. Confirmation) – ustalenie kryteriów akceptacji danej historyjki, tak, aby możliwe było wykonanie testów akceptacyjnych.

To, co jest najbardziej cenne dla większości zespołów projektowych, to czas – a user story pozwala go zaoszczędzić. Historyjki stanowią także potwierdzenie, że wszyscy w teamie zgadzają się co do sposobu tworzenia lub modyfikacji funkcjonalności, nad którą pracują. To jednak nie wszystkie zalety user story. Jakie korzyści przynosi tworzenie historyjek? Poniżej najważniejsze z nich.

Wcześniej wspomniałam już o tym, że obecnie firmy tworzące produkty i oprogramowanie, coraz prężniej pracują nad tym, aby ich oferta była dopasowana do potrzeb i wymagań klientów. User story pozwala na skupienie na końcowym odbiorcy i rozwiązywaniu realnych problemów, które napotykają. 

Stworzenie historyjki pozwala na polepszenie współpracy w zespole projektowym. Każdy wie, co należy do jego obowiązków i nad czym obecnie pracują pozostali, a dzięki elementowi konwersacji, łatwiej o spójne ustalenia. Team skupia się na wspólnym celu, jakim jest uczynienie danej funkcjonalności bardziej przydatną. Ponadto metoda ta pobudza kreatywność i poszerza perspektywy osób pracujących w projekcie. 

Format user stories pozwala na to, aby w prosty, konkretny i zwięzły sposób opisać wszystkie najważniejsze zagadnienia, które należy wprowadzić. Dzięki temu jest on technicznie zrozumiały zarówno dla Project Ownera, jak i dla deweloperów. Można opisywać nim zarówno drobne zmiany, jak i duże elementy. 

Dzięki prostej formie historyjek, które dodatkowo wspiera się metodą INVEST, tworzysz jasne opisy, ułatwiające zrozumienie korzyści, jakie idą za wdrożeniem funkcjonalności. W ten sposób skupiasz się na dostarczaniu przydatnych funkcji i popełniasz mniej błędów. 

User stories to niepozorne, choć bardzo ważne narzędzie, umożliwiające zrozumienie potrzeb użytkownika. Koncentrując się na jego potrzebach i wartościach, które chce uzyskać, historyjki przyczyniają się do sukcesu projektu. Zespoły, które korzystają z tej metody, lepiej współpracują i popełniają mniej błędów. Jeśli chcesz dostarczać klientowi wartościowe produkty, rozważ wprowadzenie user stories w swojej firmie.