Szablon opisu użytkownika i kryteria akceptacji

Szablon opisu użytkownika składa się z jednego zdania zawierającego trzy miejsca na uzupełnienie:

Jako [rola] pragnę osiągnąć [cel], aby uzyskać [korzyść].

Proszę to skopiować i wykorzystać, ale należy pamiętać, do czego służy: szablon ten stanowi punkt wyjścia do rozmowy, a nie formularz do wypełnienia. Wypełnione zdanie stanowi punkt początkowy procesu dopracowywania. To, co sprawia, że historia staje się wykonalna, to elementy dodawane w dalszej części — kryteria akceptacji, które przekształcają uzgodniony zamiar w test typu „zaliczone/niezaliczone”, oraz oszacowanie, które zamienia go w zadanie możliwe do zaplanowania. W niniejszym rozdziale przedstawiono jedną historię, która przechodzi przez wszystkie trzy etapy.

Wypełnianie luk bez zmyślania odpowiedzi

Każdy slot charakteryzuje się typową usterką, a każdą z nich można sprawdzić:

• [rola] — konkretna osoba, a nie „użytkownik”. Jeśli nie potrafiliby Państwo wskazać tej osoby na podstawie danych analitycznych lub listy zgłoszeń do działu wsparcia, rola ta jest jedynie elementem dekoracyjnym. Test: czy projektant mógłby podjąć inną decyzję ze względu na wybraną przez Państwa rolę?
• [cel] — to, co dana osoba robi, wyrażone jej własnymi słowami. „Chcę zresetować hasło” odnosi się do użytkownika; „Potrzebuję mikrousługi do resetowania hasła” odnosi się do schematu architektury. Test: czy dana osoba rzeczywiście wypowiedziałaby to zdanie?
• [korzyść] — argument przemawiający za zaplanowaniem zadania. Test: proszę usunąć tę klauzulę. Jeśli nic nie zostanie utracone, oznacza to, że korzyść nie została jeszcze zidentyfikowana.

Pełne uzasadnienie tego formatu — w tym trzy zasady „C” oraz lista kontrolna INVEST, którą powinna spełniać gotowa historia użytkownika — znajduje się w artykule Czym jest historia użytkownika?. Szesnaście praktycznych przykładów, zarówno dobrych, jak i złych, można znaleźć w artykule Przykłady historii użytkownika.

Karta zadania typu „kopiuj-wklej”

Samo zdanie nie wystarczy, by rozpocząć sprint. Oto pełny szablon karty, który warto wprowadzić jako standard — opis, kryteria, granice oraz rozmiar dodany na końcu:

Story
  As a [role], I want [goal], so that [benefit].

Acceptance criteria (3–5, each pass/fail)
  - [ ] …
  - [ ] …
  - [ ] …

Out of scope
  - What this story deliberately does NOT cover.

Notes & dependencies
  - Designs, decisions, other teams, open questions.

Size: [added by the team, after the conversation — never before]

Na tej karcie znalazły się dwa świadome wybory. „Poza zakresem” ma kluczowe znaczenie: większość sporów dotyczących szacowania wynika z tego, że dwie osoby oceniają różne zakresy, a ten jeden wiersz pozwala im tego uniknąć. Wielkość określa się na końcu: liczba zapisana na karcie przed omówieniem jej przez zespół staje się punktem odniesienia, co stanowi pierwszy z klasycznych błędów związanych z planowaniem pokerowym.

Warianty szablonów

Klasyczny szablon jest właściwym ustawieniem domyślnym, ale nie jest to jedyny kształt, który się sprawdza.

Wariant	Kształt	Proszę sięgnąć po to, gdy
Classic (Connextra)	Jako [stanowisko] pragnę [cel], aby [korzyść]	Standardowe podejście do zadań wykonywanych na rzecz użytkowników
Opis stanowiska	Kiedy [sytuacja], chcę [motywacja], aby móc [rezultat]	To właśnie moment decydujący mówi więcej niż sama osobowość — ta sama osoba w pociągu pragnie czegoś innego niż ta sama osoba przy biurku
Korzyść przede wszystkim	Aby [osiągnąć korzyść], jako [stanowisko], pragnę [cel]	Zespół wciąż formułuje korzyści w sposób cykliczny; umieszczenie tej klauzuli na początku uniemożliwia jej pominięcie
Proste sformułowanie problemu	Jedno zdanie opisujące problem, jedno opisujące wynik oraz kryteria określające, „kiedy zadanie zostanie wykonane”	Prace związane z platformą i kwestiami technicznymi, w których jedyną rzetelną stroną byłby sam zespół

Ostatni wiersz ma większe znaczenie, niż mogłoby się wydawać. Niektóre pozycje z listy zadań nie zawierają w zdaniu odniesienia do użytkownika, a udawanie, że jest inaczej, prowadzi do tworzenia wypełniaczy w stylu: „jako programista chcę, aby framework został zaktualizowany”. Dyscyplina wynikająca z szablonu — sformułowany powód oraz kryteria, które można przetestować — ma zastosowanie również w tej pracy; forma zdania nie musi być jednak taka sama.

Kryteria akceptacji: potwierdzenie na karcie

Kryteria akceptacji to warunki, od których zależy, czy dana historia zostanie uznana za zaliczoną, czy odrzuconą; są one ustalane przed rozpoczęciem prac. Na karcie pełnią one dwie funkcje: odzwierciedlają rzeczywiste ustalenia wynikające z rozmowy dotyczącej doprecyzowania oraz określają cel, do którego będzie dążyć oszacowanie nakładu pracy. Dwa formaty obejmują niemal każdą historię:

Prosta lista kontrolna dotycząca warunków niezależnych:

• Zawartość koszyka jest zachowywana przez 30 dni, niezależnie od sesji.
• Stały klient widzi swój koszyk na każdym urządzeniu, na którym jest zalogowany.
• Opróżniony koszyk pozostaje pusty (usunięte produkty nie są przywracane).

Given/When/Then – w przypadku zachowań zależnych od stanu:

• Jeśli klient ma zapisany koszyk, gdy produkt stanie się niedostępny, wtedy w koszyku produkt ten zostanie wyświetlony jako wyszarzony z etykietą „brak na stanie”, zamiast być po cichu usuwany.

Zasadniczo stosuj listę kontrolną; sięgnij po schemat „Given/When/Then”, gdy warunek wstępny wiąże się z rzeczywistą pracą. Lista powinna zawierać od trzech do pięciu pozycji — dłuższa lista zazwyczaj oznacza, że opowieść należy podzielić, a kryteria wskazują Państwu miejsca podziału. Pełne omówienie (kryteria a wymagania, kryteria a definicja zakończenia, kto je sporządza) można znaleźć w rozdziale poświęconym kryteriom akceptacji.

Przykład z obliczeniami: budynek jednopiętrowy, szablon do oszacowania

Oto przebieg prawdziwej historii, przedstawiony na podstawie powyższej karty.

Krok 1 — opis. Właściciel produktu pisze:

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.

Krok 2 — rozmowa, ujęta w postaci kryteriów. W ramach dopracowywania listy zadań zespół ujawnia niuanse, których nie oddaje samo zdanie, i zapisuje je:

• Klient może sfinalizować transakcję, podając jedynie adres e-mail i dane dotyczące dostawy, bez konieczności podawania hasła.
• W wiadomości e-mail z potwierdzeniem zamówienia oferowana jest możliwość utworzenia konta jednym kliknięciem (zamówienie jest już dołączone).
• Dział obsługi klienta może zidentyfikować zamówienie złożone przez gościa na podstawie numeru zamówienia oraz adresu e-mail.
• W przypadku realizacji transakcji jako gość stosowane są te same mechanizmy kontroli oszustw, co w przypadku realizacji transakcji z wykorzystaniem konta.

Poza zakresem: konwersja historycznych zamówień gości w przypadku późniejszego utworzenia konta.

Krok 3 — sprawdzenie gotowości. Cztery kryteria, jedno wyraźnie wymienione wykluczenie, brak niepotwierdzonych zależności: zadanie spełnia definicję gotowości i trafia do zespołu w celu oszacowania zakresu.

Krok 4 — oszacowanie. Zespół głosuje w rundzie planning poker. Wylosowano karty o wartościach 3, 5, 5, 8. Wynik 8 wynika z następującej przyczyny: kryterium weryfikacji oszustw wiąże się z koniecznością ingerencji w integrację z dostawcą usług płatniczych, czego nikt inny nie uwzględnił w swoich szacunkach. To właśnie kryteria spełniają swoją rzeczywistą rolę — dyskusja dotyczy zakresu prac, a nie tego, czyja liczba jest prawidłowa. Zespół ponownie głosuje i uzgadnia liczbę 5.

Proszę zwrócić uwagę na kolejność: najpierw kryteria, potem punkty. Zgłoszenie oszacowane przed ustaleniem kryteriów powoduje powstanie szerokich, niemożliwych do rozstrzygnięcia przedziałów, które hamują przebieg sesji określania wielkości — zespół głosuje nad różnymi zgłoszeniami, które przypadkowo mają ten sam tytuł.

Najczęściej zadawane pytania

Czym jest szablon opisu użytkownika?

„Jako [rola] pragnę [cel], aby [korzyść]”. Rola określa, kto odniesie korzyść, cel określa zdolność z punktu widzenia tej osoby, a korzyść stanowi powód, dla którego dane zadanie zasługuje na umieszczenie w backlogu. Szablon ten stanowi punkt wyjścia do rozmowy, a nie formularz do wypełnienia — właśnie od wypełnienia pustych pól rozpoczyna się proces dopracowywania.

Jak sformułować kryteria akceptacji dla opisu użytkownika?

Proszę sformułować od trzech do pięciu warunków, które można poddać weryfikacji i które jednoznacznie wskazują – „zdał” lub „nie zdał” – czy opowieść spełniła ustalone wymagania. Proszę skorzystać z prostej listy kontrolnej, gdy warunki są niezależne, oraz z schematu „Given/When/Then”, gdy zachowanie zależy od stanu. Każde kryterium powinno dać się zweryfikować przez testera, który nie brał udziału w rozmowie dotyczącej dopracowania opowieści.

Czy w kryteriach akceptacji należy stosować schemat „Given/When/Then”, czy też listę kontrolną?

Dopasuj format do zachowania. Schemat „Given/When/Then” sprawdza się wtedy, gdy wynik zależy od stanu początkowego, ponieważ zmusza do określenia warunku wstępnego, czynnika wyzwalającego i wyniku. Lista kontrolna jest szybsza w czytaniu i trudniejsza do nadmiernego rozbudowywania, gdy opis wymaga jedynie stwierdzenia: „te cztery rzeczy muszą być spełnione”. W przypadku większości opisów wystarczy właśnie lista kontrolna.

Czym jest opis zadania?

Wariant, w którym postać zastępuje się sytuacją: „Kiedy [sytuacja], chcę [motywacja], aby móc [rezultat]”. Opisy zadań wywodzą się ze szkoły „jobs-to-be-done” i sprawdzają się dobrze, gdy moment wyzwalający lepiej wyjaśnia wymagania niż persona — ta sama osoba ma różne potrzeby przy biurku i w pociągu.

Czy każda pozycja w backlogu wymaga szablonu opisu użytkownika?

Nie. Szablon ten opisuje wartość odczuwalną przez użytkownika, a narzucanie go w odniesieniu do pracy na platformach, znanych błędów lub projektów badawczych prowadzi do powstania zdań, które wprowadzają zbędną formalność, nie wnosząc przy tym żadnych informacji. Należy zachować dwa elementy, które zawsze mają zastosowanie — jasno określony powód oraz weryfikowalne kryteria akceptacji — a formę zdania dostosować do charakteru danego zadania.

Warto przeczytać

• Szacowanie w metodologii agile: kompletny przewodnik — tutaj znajdą Państwo wszystkie niezbędne informacje.
• Czym jest historia użytkownika? — uzasadnienie szablonu: trzy zasady „C” oraz INVEST.
• Przykłady historii użytkownika — szesnaście opatrzonych komentarzami historii, które posłużą jako punkt odniesienia.
• Kryteria akceptacji: jak je sformułować — pełny rozdział poświęcony etapowi weryfikacji.
• Definicja „gotowy” — etap, który historia oparta na szablonie musi przejść, aby zostać włączona do sprintu.
• Czym są punkty fabularne? — jednostka, w której określa się wielkość ukończonej karty.