Przykłady opowieści użytkownika: 16 opowieści z komentarzami – dobre i złe

Szesnaście przykładów opowieści użytkownika wraz z objaśnieniami, obejmujących takie obszary jak uwierzytelnianie, handel elektroniczny, aplikacje mobilne, interfejsy API oraz błędy; obok niepoprawnych wersji zamieszczono ich poprawione wersje, dzięki czemu różnica jest wyraźnie widoczna.

Szesnaście przykładów historii użytkownika, zaczerpniętych z dziedzin, w których zespoły faktycznie pracują: uwierzytelnianie, handel elektroniczny, technologie mobilne, interfejsy API, błędy oraz narzędzia wewnętrzne. Każda z nich zawiera objaśnienia: nie tylko co mówi dana historia, ale także dlaczego klauzule dotyczące roli i korzyści są tak istotne. Cztery z nich są celowo źle sformułowane i przedstawione obok ich poprawionych wersji, ponieważ najszybszym sposobem na opanowanie tego formatu jest obserwowanie, jak się on nie sprawdza.

Jeśli sam format jest dla Pana/Pani nowością, proszę zacząć od Czym jest historia użytkownika?. W skrócie: każda historia ma tutaj formę „Jako [rola], chcę [cel], aby [korzyść]”, a każda dobra historia może trafić bezpośrednio do etapu dopracowywania i rundy planning poker.

Uwierzytelnianie i konta

1. Zaloguj się

Jako stały klient pragnę zalogować się przy użyciu adresu e-mail i hasła, aby móc przejrzeć historię moich zamówień.

Dlaczego to działa: rola ta ma konkretny charakter. Określenie „powracający klient” wskazuje, że dana osoba posiada konto, dokonywała już wcześniej zamówień i ma powód, by powrócić: są to trzy fakty, które mogą wykorzystać zarówno projektant, jak i tester. Sformułowanie „jako użytkownik” nie zawierałoby żadnego z nich.

2. Zresetowanie hasła

Jako użytkownik, który nie ma dostępu do konta, pragnę zresetować hasło z poziomu ekranu logowania, aby móc ponownie uzyskać dostęp do konta bez konieczności kontaktowania się z działem pomocy technicznej.

Dlaczego to działa: w klauzuli dotyczącej korzyści wymieniono konkretny koszt. Każde zresetowanie, które trafia do działu wsparcia, oznacza wymierny koszt finansowy, więc tę sprawę można potraktować priorytetowo w stosunku do innych na podstawie faktów, a nie subiektywnych odczuć. Proszę zwrócić uwagę na to, czego to zdanie nie obejmuje: wygaśnięcia tokenu, limitów częstotliwości ani szablonu wiadomości e-mail. Te szczegóły powinny znaleźć się w kryteriach akceptacji, sporządzonych w momencie dopracowania ich przez zespół:

  • W ciągu dwóch minut od złożenia wniosku otrzymają Państwo wiadomość e-mail z linkiem do zresetowania hasła.
  • Link do zresetowania konta traci ważność po upływie jednej godziny i można z niego skorzystać tylko raz.
  • Formularz zwraca tę samą odpowiedź niezależnie od tego, czy adres e-mail istnieje, czy nie (nie następuje wyliczanie kont).

3. Opowieść o kołowym cyklu

Jako użytkownik chcę się zalogować, aby uzyskać dostęp do aplikacji.

Dlaczego to nie działa: wszystkie pola są wypełnione, ale nie przekazano żadnej treści. Rola nie odnosi się do konkretnej osoby, a korzyść stanowi powtórzenie celu, więc zdanie z „aby” można by usunąć bez utraty informacji. Taka historia przechodzi kontrolę formalną, pomijając jednak cały proces refleksji, do którego ta kontrola ma skłaniać.

Nowa wersja:

Jako członek zespołu powracający w trakcie sprintu chciałbym po zalogowaniu się automatycznie przejść do tablicy, którą oglądałem jako ostatnią, aby nie musieć codziennie rano ponownie do niej nawigować.

Oto osoba, chwila i korzyść, które można rozważyć w kontekście innych obowiązków służbowych.

Handel elektroniczny

4. Trwałość zawartości koszyka

Jako klient przeglądający ofertę podczas przerwy obiadowej chciałbym, aby produkty pozostały w moim koszyku, gdy wrócę tu wieczorem, tak abym nie musiał szukać wszystkiego od nowa.

Dlaczego to działa: rola zawiera scenariusz. Sformułowanie „przeglądanie stron w przerwie obiadowej” wyjaśnia, dlaczego koszyki są porzucane w trakcie procesu zakupowego, co wskazuje zespołowi, że istotny jest okres utrzymywania zainteresowania liczony w godzinach, a nie w sekundach. Dobrze dobrana rola pozwala zawrzeć kontekst w jednym zdaniu.

5. Realizacja zamówienia jako gość

Jako osoba dokonująca zakupu po raz pierwszy chciałbym przejść do kasy bez zakładania konta, aby móc sfinalizować zakup, zanim zmienię zdanie.

Dlaczego to działa: przedstawia pozycjonowanie produktu (konta są opcjonalne) i wskazuje rzeczywistą korzyść: wahanie się uniemożliwia dokonanie pierwszego zakupu. Tak jasno sformułowane argumenty pozwalają również wcześnie ujawnić ewentualne rozbieżności: jeśli firma oczekuje, że każdy nabywca będzie posiadał konto, spór ten zostanie rozstrzygnięty na etapie dopracowywania projektu, a nie w ramach pull requestu.

6. Postać ubrana w kostium z opowieści

Jako klient pragnę, aby proces realizacji transakcji przebiegał szybciej i był bardziej przejrzysty, co pozwoli zwiększyć współczynnik konwersji.

Dlaczego to się nie sprawdza: z dwóch powodów. „Szybciej, czystiej” nie jest cechą, którą ktokolwiek może stworzyć lub przetestować, a „poprawa konwersji” stanowi korzyść dla firmy, a nie dla klienta. Żaden klient nie pragnie konwersji. Jest to efekt pracy trwającej cały kwartał skondensowany w jednym zdaniu, co sprawia, że jest to epopeja, a nie opowieść.

Przeróbka (jej fragment):

Jako klient dokonujący zakupów za pomocą telefonu komórkowego pragnę, aby mój adres wysyłki był automatycznie uzupełniany na podstawie kodu pocztowego, co pozwoli mi sfinalizować transakcję jedną ręką.

Epopeja staje się zbiorem takich fragmentów, z których każdy można przetestować i który jest wystarczająco mały, by go ogarnąć.

Urządzenia mobilne

7. Tryb offline

Jako technik terenowy pragnę, aby dzisiejszy arkusz zlecenia ładował się bez połączenia z internetem, abym mógł kontynuować pracę w piwnicach i obszarach bez zasięgu.

Dlaczego to działa: to właśnie ta rola określa wymagania. Pracownicy biurowi nigdy nie mają styczności z obsługą w trybie offline; technicy terenowi natomiast nie mogą się bez niej obejść. Kiedy podczas doprecyzowywania ktoś pyta: „Jak bardzo offline oznacza tryb offline?”, ta rola udzieliła już odpowiedzi: wszędzie tam, gdzie zaprowadzi ich praca.

8. Preferencje dotyczące powiadomień

Jako subskrybent otrzymujący trzy powiadomienia push dziennie chciałbym móc wybrać, które rodzaje alertów mają generować powiadomienia, abym nie musiał wyciszać całej aplikacji.

Dlaczego to działa: korzyść określa konkretny scenariusz niepowodzenia, któremu zapobiega dany przypadek użycia. Użytkownicy nie narzekają na liczbę powiadomień; po prostu wyciszają aplikację i po cichu z niej rezygnują. Przypadek użycia, który określa to „ciche” zachowanie, przed którym ma chronić, jest tematem, nad którym zespół może szczerze dyskutować.

Interfejsy API i prace techniczne

9. Paginacja

Jako programista ds. integracji pragnę, aby odpowiedzi w punkcie końcowym /events były paginowane, tak aby moja nocna synchronizacja nie kończyła się przekroczeniem limitu czasu w przypadku dużych kont.

Dlaczego to działa: oto prawdziwa techniczna historia użytkownika: programista jest rzeczywistym, zewnętrznym użytkownikiem mającym własne cele, a nie zespołem, który sam się w to zdanie wplata. Użytkownicy API, autorzy wtyczek oraz operatorzy dyżurni – wszyscy oni spełniają ten warunek.

10. Ograniczanie częstotliwości

Jako użytkownik interfejsu API oczekuję, że po osiągnięciu limitu częstotliwości otrzymam odpowiedź 429 z nagłówkiem „Retry-After”, tak aby mój klient mógł wstrzymać się z kolejnymi próbami zamiast przerywać całe zadanie.

Dlaczego to działa: cel jest na tyle precyzyjny, że sam w sobie stanowi pierwsze kryterium akceptacji, a jednocześnie odnosi się do tego, co ma zostać zrealizowane, a nie do sposobu, w jaki ma to nastąpić: nic tutaj nie narzuca konkretnej implementacji ogranicznika.

11. Refaktoryzacja pod przykrywką

Jako programista pragnę przeprowadzić refaktoryzację modułu płatności, aby kod był bardziej przejrzysty.

Dlaczego to się nie sprawdza: rolą jest zespół, celem jest działanie, a nie wynik, a pojęcia „czystsze” nie da się zweryfikować. Jest to format opowieści zastosowany do zadania, do którego nie został zaprojektowany – przypadek ten omówiono w artykule „Kiedy opowieści użytkownika są niewłaściwym narzędziem”.

Nowa wersja (celowo nie jest to opowieść użytkownika):

Należy zmniejszyć zależność modułu płatności od konkretnego dostawcy, tak aby można było dodać nowego dostawcę usług płatniczych bez ingerencji w podstawowy proces realizacji transakcji. Zadanie uznaje się za wykonane, gdy: interfejs dostawcy zostanie wyodrębniony, obaj dotychczasowi dostawcy będą działać w oparciu o niego, a zestaw testów integracyjnych zakończy się powodzeniem bez wprowadzania zmian.

Prosty element techniczny z jasno określonym rezultatem zawsze przewyższa opowieść pełną kostiumów.

Błąd czy zgłoszenie?

12. Błąd, który jest opowieścią

Jako klient korzystający z planu rocznego pragnę, aby na mojej fakturze widniała zniżka, którą mi zaproponowano, tak aby dział finansowy mógł ją rozliczyć bez konieczności zgłaszania zapytania do działu pomocy technicznej.

Dlaczego to działa: przyczyna jest znana, a zakres poprawki jest jasno określony, więc zadanie to funkcjonuje tak samo jak każde inne: ma kryteria, wielkość oraz miejsce w sprincie. Praca nad konkretnymi błędami zapewnia, że velocity rzetelnie odzwierciedla rzeczywiste wykorzystanie zdolności produkcyjnej; rozdział poświęcony punktom opowieści w pełni uzasadnia tę tezę.

13. Błąd, który nim nie jest

Klienci sporadycznie zgłaszają, że opłata została naliczona dwukrotnie. Nie udało się wiarygodnie odtworzyć tego błędu.

Dlaczego nie jest to historia: nie ma tu miejsca na obietnicę. Zdanie typu „rola-cel-korzyść” („Jako klient nie chcę, aby naliczono mi podwójną opłatę…”) byłoby prawdziwe, ale bezużyteczne, a każda prognoza odzwierciedlałaby jedynie nadzieję. Właściwym posunięciem jest przeprowadzenie ograniczonego czasowo spike’u: przeprowadzić dwudniowe badanie, przedstawić uzyskane wnioski, a następnie napisać rzeczywisty opis zmiany wprowadzającej poprawkę.

Narzędzia wewnętrzne i sprawozdawczość

14. Oprzyrządowanie pomocnicze

Jako konsultant obsługi klienta w czacie na żywo chciałbym mieć wgląd w pięć ostatnich prób logowania danego klienta, aby na pierwszy rzut oka móc odróżnić przypadek zapomnianego hasła od zablokowanego konta.

Dlaczego to działa: użytkownicy wewnętrzni to przecież również użytkownicy. Korzyść mierzy się w sekundach na zgłoszenie, a jest to właśnie ten konkretny wskaźnik, który pozwala tej historii konkurować o miejsce w sprincie z zadaniami skierowanymi do klientów, zamiast z góry przegrywać.

15. Eksport

Jako kierownik zespołu chciałbym wyeksportować raport ze sprintu w formacie CSV, aby móc udostępnić wyniki interesariuszom, którzy nie posiadają kont.

Dlaczego to działa: zdanie z „aby” w dyskretny sposób określa zakres zadania. Zadaniem jest udostępnianie poza narzędziem, co wyklucza rozwiązania takie jak pulpity nawigacyjne w aplikacji oraz reguły zapisane w nudnym, przenośnym formacie CSV. Dobrze sformułowana klauzula korzyści wykonuje pracę projektową za darmo.

16. Epopeja widoczności

Jako kierownik pragnę dysponować pulpitem nawigacyjnym przedstawiającym wszystkie działania zespołu, aby mieć pełny wgląd w sytuację.

Dlaczego to nie działa: „wszystko” nie stanowi zakresu, a „widoczność” nie jest rezultatem: nic z tego nie da się stworzyć, przetestować ani oszacować. Za takim opisem kryje się prawdziwe pytanie, którego kierownik jeszcze nie został zapytany.

Nowa wersja:

Jako kierownik ds. realizacji, przygotowujący poniedziałkową telekonferencję podsumowującą, pragnę, aby na jednej stronie znalazły się cele sprintu każdego zespołu wraz z ich statusem (czerwony/pomarańczowy/zielony), tak abym mógł wskazać zablokowane zadania bez konieczności kontaktowania się z każdym kierownikiem.

Ta sama osoba, ten sam instynkt, ale teraz wszystko wpisuje się w ramy sprintu, a tester wie, kiedy zadanie jest zakończone.

Cechy wspólne osób, które odnoszą sukcesy

Proszę przyjrzeć się tym dwunastu, które się sprawdzają. Każde z nich wskazuje konkretną osobę, która może wyrazić opinię, określa cel, który ta osoba rozpozna, oraz wiąże się z korzyścią, która wytrzyma jedno szczere pytanie „dlaczego?”. Żadne z nich nie zawiera szczegółów dotyczących wdrożenia i żadne nie stara się być kompletne. Do tego właśnie służą kryteria akceptacji oraz rozmowa dotycząca dopracowania.

Te cztery złe przykłady zawodzą dokładnie na dwa sposoby, co jest budujące: albo korzyść ma charakter cykliczny (nikt nie sprawdził, dlaczego), albo zakres jest zbyt rozległy (nikt nie sprawdził, jak duży). Oba rodzaje niepowodzeń ujawniają się w momencie, gdy Państwa zespół próbuje oszacować zadanie, dlatego sesje szacowania pozwalają wykryć złe zadania szybciej niż jakiekolwiek wytyczne dotyczące pisania: duża rozbieżność w głosach stanowi komunikat o błędzie tego formatu. Proszę napisać kolejną partię opartą na szablonie, a następnie przedstawić je zespołowi przy użyciu planning pokera i sprawdzić, które z nich zyskają poparcie.

Najczęściej zadawane pytania

Jaki jest przykład historii użytkownika?

„Jako stały klient chcę zalogować się przy użyciu adresu e-mail i hasła, aby móc przejrzeć historię moich zamówień”. Wymienia konkretną osobę, określa funkcję z jej punktu widzenia oraz podaje powód, dla którego warto zaplanować wykonanie tego zadania. Ta trzyczęściowa struktura (rola, cel, korzyść) stanowi klasyczny format opisu użytkownika.

Jak napisać dobrą historię użytkownika?

Proszę określić konkretną rolę zamiast ogólnego terminu „użytkownik”, sformułować cel jako działanie wykonywane przez daną osobę, a nie jako element zawarty w systemie, oraz zakończyć zdanie z frazą „aby” korzyścią, która wytrzymałaby szczere pytanie „dlaczego?”. Następnie proszę dołączyć kryteria akceptacji, ponieważ zdanie opisujące historię użytkownika stanowi punkt wyjścia do rozmowy, a nie sam wymóg.

Czy zadania techniczne można sformułować w formie historii użytkownika?

Czasami. Jeśli „użytkownik” jest rzeczywistą osobą (programistą zajmującym się integracją, korzystającym z Państwa API, lub operatorem pełniącym dyżur), format ten sprawdza się zgodnie z opisem. Jeśli jedyną właściwą rolą jest „zespół”, proszę zrezygnować z tej konwencji i sformułować prosty element techniczny, określając konkretny rezultat oraz kryteria akceptacji. Zasada pozostaje ta sama; forma zdania nie musi się zmieniać.

Czy zgłoszenia błędów powinny być formułowane jako historie użytkownika?

Błąd o znanej przyczynie i jasnym sposobie naprawy może być uwzględniony, a wskazanie go pozwala zachować rzetelność wskaźnika prędkości. Błąd, którego nikt nie jest w stanie odtworzyć, nie może być uwzględniony: nie ma tu podstaw do składania obietnic, więc opisywaną pozycję można by potraktować jedynie jako przypuszczenie z klauzulą dotyczącą korzyści. Najpierw należy wyznaczyć ramy czasowe na przeprowadzenie analizy, a następnie sformułować rzeczywisty opis pozycji na podstawie jej wyników.

Jak szczegółowa powinna być historia użytkownika?

Jedno zdanie opisujące przypadek użycia, a następnie od trzech do pięciu kryteriów akceptacji. To zdanie stanowi punkt wyjścia do dyskusji; kryteria odzwierciedlają wyniki tej dyskusji. Jeśli lista kryteriów przekracza liczbę pięciu, oznacza to, że dany przypadek użycia składa się z kilku odrębnych przypadków, a kryteria wskazują Państwu, w którym miejscu należy go podzielić.

Warto przeczytać