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

Szesnaście przykładów historii użytkownika z obszarów uwierzytelniania, handlu elektronicznego, aplikacji mobilnych, interfejsów API oraz błędów — każda z nich opatrzona jest komentarzami, a obok niepoprawnych 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, e-commerce, technologie mobilne, interfejsy API, błędy oraz narzędzia wewnętrzne. Każda z nich zawiera objaśnienia — nie tylko dotyczące tego, co mówi dana historia, ale także wyjaśniające, 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 artykułu Czym jest historia użytkownika? — w skrócie: każda historia tutaj ma następującą 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 jest konkretna. Określenie „powracający klient” wskazuje, że dana osoba posiada konto, złożyła już wcześniej zamówienie 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, przekłada się na wymierną kwotę pieniężną, dzięki czemu 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 wygasa 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 przeszukiwania listy 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ę 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ę automatycznie przejść 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 porównać z innymi zadaniami.

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, 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ę zniechęca do pierwszego zakupu. Tak jasno sformułowane opisy pozwalają również wcześnie ujawnić ewentualne rozbieżności: jeśli firma chce, aby każdy kupujący posiadał konto, spór ten rozstrzyga się 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 nie działa: 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 chciałbym, aby mój adres wysyłki był automatycznie uzupełniany na podstawie kodu pocztowego, dzięki czemu będę mógł sfinalizować zamówienie 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 chciałbym, 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 w ogóle nie zauważają wsparcia w trybie offline; technicy terenowi natomiast nie mogą się bez niego obejść. Kiedy podczas doprecyzowywania ktoś pyta: „Jak bardzo offline oznacza tryb offline?”, ta rola już udzieliła odpowiedzi — gdziekolwiek 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 dana historia. Użytkownicy nie narzekają na liczbę powiadomień; po prostu wyciszają aplikację i po cichu ją opuszczają. Historia, która określa konkretne, niezauważalne 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 potrzebuję odpowiedzi z paginacją w punkcie końcowym /events, aby moja nocna synchronizacja nie kończyła się przekroczeniem limitu czasu w przypadku dużych kont.

Dlaczego to działa: jest to uzasadniona techniczna historia użytkownika — programista jest prawdziwym, 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 realizacji — nic tutaj nie narzuca konkretnego sposobu wdrożenia ogranicznika.

11. Refaktoryzacja pod przykrywką

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

Dlaczego to nie działa: 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ł 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 uznaje się 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 konkretnie określić, zawsze przewyższa opowieść pełną fantazji.

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ł dokonać uzgodnienia bez konieczności zgłaszania zapytania do działu pomocy technicznej.

Dlaczego to działa: przyczyna jest znana, a zakres poprawki jasno określony, więc zachowuje się to tak jak każda inna historia — ma kryteria, wielkość i miejsce w sprincie. Przypisywanie punktów do błędów zapewnia, że wskaźnik velocity rzetelnie odzwierciedla rzeczywiste wykorzystanie zdolności produkcyjnej; rozdział poświęcony punktom historii wyjaśnia tę kwestię szczegółowo.

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

Klienci sporadycznie zgłaszają, że zostali obciążeni dwukrotnie. Nie udało się wiarygodnie odtworzyć tego błędu.

Dlaczego nie jest to historia: nie ma tu miejsca na obietnice. 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 sprowadzałaby się do wyrażenia nadziei. Właściwym rozwiązaniem jest przeprowadzenie ograniczonego czasowo spike’u: dwa dni na zbadanie problemu, przedstawienie uzyskanych wniosków, a następnie napisanie prawdziwego opisu 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 wskaźnik, który pozwala temu zgłoszeniu 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” dyskretnie 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 — niczego 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 oraz ich status (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ę tym dwunastu, które się sprawdzają. Każdy 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?”. Żaden z nich nie zawiera szczegółów wdrożenia i żaden nie próbuje być kompletny — do tego 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ć kartę, dlatego sesje szacowania pozwalają wykryć złe karty 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ę 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 jej kompetencje 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 uzupełnić część zdania zaczynającą się od „aby” korzyścią, która wytrzymałaby jedno 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 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ą 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. Dyscyplina pozostaje ta sama; forma zdania nie musi się zmieniać.

Czy zgłoszenia błędów należy formułować jako opisy 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 domysłem 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ć.

Warto przeczytać