User story na podstawie wywiadu: szablon i kryteria akceptacji

Historyjka użytkownika opisuje wartość

Historyjka użytkownika krótko przedstawia oczekiwany rezultat z perspektywy osoby, która będzie używać produktu. Często ma formę „Jako [rola] chcę [działanie], aby [korzyść]”. To punkt wyjścia do rozmowy o potrzebie. Wymagania i sposób weryfikacji trzeba jeszcze ustalić.

Słowa „dodajcie zielony przycisk” zawierają propozycję rozwiązania. Aby napisać historyjkę, ustal, co rozmówca próbuje osiągnąć i co mu przeszkadza w obecnym przebiegu pracy. Zachowaj cytat, aby móc sprawdzić interpretację.

Jak napisać historyjkę na podstawie wywiadu

1. Wybierz konkretny przypadek

   Znajdź opis ostatniego rzeczywistego przypadku. Kto działał, z jakim materiałem i czego oczekiwał? Ogólna uwaga „wszyscy potrzebują raportów” to za mało, by utworzyć osobną historyjkę.

2. Zapisz dokładną wypowiedź i kontekst

   Zachowaj znacznik czasu i kilka sąsiednich zdań. Oddziel słowa rozmówcy od własnego wniosku. Wyjątkowego przypadku nie opisuj jako codziennego zadania.

3. Określ rolę, działanie i korzyść

   Rola ma wyjaśniać sytuację, zamiast ograniczać się do etykiety „użytkownik”. Działanie ma być obserwowalne, a korzyść ma wyjaśniać, po co tej osobie to działanie.

4. Sprawdź zakres

   Wydziel jeden kompletny, użyteczny wynik, który można osobno omówić i sprawdzić. Unikaj ujmowania całej ścieżki od rejestracji do raportu rocznego w jednej historyjce.

5. Dodaj kryteria akceptacji

   Opisz warunki, po których można poznać, że wdrożono oczekiwane zachowanie. Uwzględnij przypadek główny i istotny wyjątek. Uzgodnij kryteria z zespołem przed uznaniem ich za wymagania klienta.

6. Wróć do pytań otwartych podczas rozmowy

   Jeśli uprawnienia, wielkość danych lub format wyniku nie są znane, zapisz pytanie wprost. Nie uzupełniaj luk najczęściej spotykanym rozwiązaniem.

Od wypowiedzi koordynatora do karty historyjki

Przykład dotyczy fikcyjnego systemu notatek. Nie opisuje obecnych funkcji Transkribatora. Potrzebą jest przekazanie wybranego fragmentu bez zbędnych informacji. Kolor ewentualnego przycisku to decyzja projektowa.

Historyjka ma źródło, ale jej znaczenie dla większości klientów wymaga potwierdzenia. Jedno nagranie pokazuje jedno doświadczenie. Ustal priorytet osobno, uwzględniając inne dowody, cele produktu i koszt wdrożenia.

Jak odróżnić historyjkę od listy zadań technicznych

„Utworzyć tabelę w bazie” lub „dodać procedurę obsługi zdarzeń” to zadania techniczne. Mogą należeć do realizacji historyjki, ale nie wyjaśniają korzyści użytkownika. Zgrabne zdanie według szablonu też nie gwarantuje, że zespół rozumie wszystkie ograniczenia.

Opowiedz historyjkę osobie testującej bez nazywania elementu interfejsu. Jeśli nie potrafisz opisać czynności użytkownika przed zmianą i po niej, wróć do wywiadu. Sprawdź też przypadki negatywne: brak wybranych danych, niewystarczające uprawnienia lub ponowną próbę. Uwzględnij tylko istotne wyjątki, by karta nie stała się specyfikacją całego produktu.

Karta ze źródłem i pytaniami otwartymi

Tytuł historyjki:
Rola i sytuacja w pracy:
Jako [kto] chcę [co zrobić], aby [po co].

Źródło: wywiad / data / znacznik czasu:
Oryginalna wypowiedź:
Nasza interpretacja:

Kryteria akceptacji:
1. Przy [warunek] osoba może [działanie] i uzyskuje [rezultat].
2. Jeśli [istotny wyjątek], następuje [oczekiwane zachowanie].

Poza zakresem historyjki:
Do wyjaśnienia:
Kto i kiedy potwierdził sformułowanie:

• Rola jest konkretna, a korzyść jasna.
• Cytat oddzielono od rozwiązania zespołu.
• Kryteria można zweryfikować przez obserwację.
• Pytania pozostały pytaniami.