Postać w postaci karteczki samoprzylepnej z markerem, stojąca obok tablicy z kartami fabularnymi, odhaczająca je i podnosząca jedną kartę, aby przyjrzeć się jej bliżej.

Przykłady historii użytkownika: 16 opatrzonych komentarzami historii – dobrych i złych

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 pierwotnych wersji przedstawiono ich poprawione wersje, dzięki czemu różnice są wyraźnie widoczne.

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 przedstawiono je obok ich poprawionych wersji, ponieważ najszybszym sposobem na opanowanie tego formatu jest obserwowanie, jak się on nie sprawdza.

Jeśli sam format jest dla Państwa nowością, proszę zacząć od pytania: „Czym jest historia użytkownika?”. Krótko mówiąc, każda historia ma tutaj następującą strukturę: „Jako [rola], chcę [cel], aby [korzyść]”, a każda dobra historia może zostać bezpośrednio wykorzystana w procesie dopracowywania oraz rundzie planowania pokerowego.

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, złożyła już zamówienie i ma powód, by powrócić: są to trzy fakty, które mogą wykorzystać zarówno projektant, jak i tester. Określenie „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, wiąże się z wymiernymi kosztami, 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 należą do kryteriów akceptacji, które zostaną sformułowane podczas dopracowywania zadania 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 (bez sprawdzania listy kont).

3. Opowieść o kołowym cyklu

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

Dlaczego nie spełnia wymagań: wszystkie pola są wypełnione, ale nie zawiera ż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ę formatową, 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ę przejść bezpośrednio do tablicy, którą oglądałem jako ostatnią, aby nie musieć codziennie rano na nowo do niej przechodzić.

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

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, dzięki czemu nie będę 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 zrealizować zamówienie bez zakładania konta, aby móc sfinalizować zakup, zanim zmienię zdanie.

Dlaczego to działa: określa pozycję produktu (konta są opcjonalne) i przedstawia rzeczywistą korzyść: wahanie się zniechęca do pierwszego zakupu. Tak jasno sformułowane opisy pozwalają również wcześnie ujawnić rozbieżności: jeśli firma chce, aby każdy nabywca posiadał konto, spór ten rozstrzyga się na etapie dopracowywania produktu, a nie w ramach pull requestu.

6. Metrik w kostiumie z bajki

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ą każdy 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 epos, a nie opowieść.

Przeróbka (jej fragment):

Jako klient dokonujący zakupów za pomocą telefonu komórkowego chciałbym, 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 na tyle mały, że można go łatwo 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 mieć możliwość wyboru, które rodzaje alertów mają generować powiadomienia, abym nie musiał wyciszać całej aplikacji.

Dlaczego to działa: korzyść określa konkretny rodzaj niepowodzenia, któremu zapobiega dana historia. Użytkownicy nie narzekają na liczbę powiadomień; po prostu wyciszają aplikację i po cichu ją opuszczają. Historia, która określa ciche zachowanie, przed którym ma chronić, jest historią, nad którą 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 kolejną próbą 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 konkretnego sposobu realizacji 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 w kontekście, do którego nie został stworzony – przypadek omówiony 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 zostanie uznane za wykonane, gdy: interfejs dostawcy zostanie wyodrębniony, obaj dotychczasowi dostawcy będą działać w oparciu o ten interfejs, a zestaw testów integracyjnych zakończy się powodzeniem bez wprowadzania zmian.

Prosty element techniczny, którego rezultat można jednoznacznie określić, zawsze przewyższa opowieść opartą na kostiumach.

Błąd czy funkcja?

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ą uzgodnić 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 zachowuje się to tak jak każda inna historia: otrzymuje kryteria, wielkość oraz miejsce w sprincie. Praca nad konkretnymi błędami pozwala na rzetelne odzwierciedlenie w wskaźniku prędkości rzeczywistego wykorzystania zdolności produkcyjnej; rozdział poświęcony punktom historii szczegółowo uzasadnia tę tezę.

13. Błąd, który nie jest błędem

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

Dlaczego nie jest to „story”: 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 rozwiązaniem jest przeprowadzenie ograniczonego czasowo badania wstępnego: przeprowadzić analizę przez dwa dni, przedstawić uzyskane wnioski, a następnie sformułować rzeczywisty opis zadania dotyczącego wprowadzenia poprawki.

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 wymiar, 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 subtelny 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ę mieć pulpit nawigacyjny zawierający wszystkie działania zespołu, aby mieć pełny wgląd w sytuację.

Dlaczego to się nie sprawdza: „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ę mieć na jednej stronie cele sprintu każdego zespołu wraz z ich statusem (czerwony/pomarańczowy/zielony), aby móc 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 odniosły sukces

Proszę przyjrzeć się ponownie dwunastu kryteriom, które się sprawdzają. Każde z nich określa 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 wdrożeniowych i żadne nie ma charakteru wyczerpującego. Do tego właśnie służą kryteria akceptacji oraz rozmowa dotycząca doprecyzowania.

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). Obie te wady ujawniają się w momencie, gdy Państwa zespół próbuje oszacować kartę opowieści, dlatego sesje szacowania pozwalają wykryć złe karty opowieści szybciej niż jakiekolwiek wytyczne dotyczące pisania: duża rozbieżność w głosach jest komunikatem o błędzie tego formatu. Proszę napisać kolejną partię kart zgodnie z szablonem, a następnie przedstawić je zespołowi przy użyciu planowania pokerowego i sprawdzić, które z nich uzyskają zbieżne wyniki.

Najczęściej zadawane pytania

Jaki jest przykład historii użytkownika?

„Jako stały klient pragnę 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ć to zadanie. 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ć część „aby” korzyścią, która wytrzymałaby jedno szczere pytanie „dlaczego?”. Następnie proszę dołączyć kryteria akceptacji, ponieważ zdanie opisujące opowieść stanowi punkt wyjścia do rozmowy, a nie sam wymóg.

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

Czasami. Jeśli „użytkownik” jest rzeczywistą osobą (programistą zajmującym się integracją, korzystającym z Państwa API, lub operatorem dyżurnym), format ten sprawdza się zgodnie z opisem. Jeśli jedyną autentyczną 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 należy formułować jako historie użytkownika?

Błąd o znanej przyczynie i jasnym rozwiązaniu może być uwzględniony, a wskazanie go pozwala na rzetelne oszacowanie prędkości realizacji. Błąd, którego nikt nie jest w stanie odtworzyć, nie może być uwzględniony: nie ma podstaw do składania obietnic, więc opis zadania byłby jedynie przypuszczeniem opatrzonym klauzulą dotyczącą korzyści. Najpierw należy wyznaczyć ramy czasowe na przeprowadzenie analizy, a następnie sformułować rzeczywisty opis zadania w oparciu o jej wyniki.

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

Jedno zdanie opisujące scenariusz, 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 scenariusz składa się z kilku odrębnych scenariuszy, a kryteria wskazują, w którym miejscu należy go podzielić.

Materiały powiązane