Historia użytkownika to krótki, prosty opis funkcji napisany z perspektywy użytkownika. Zawiera informacje kto chce coś, co chce i dlaczego. Kryteria akceptacji definiują, co oznacza "gotowe" dla tej historii — warunki, które muszą być spełnione, aby została zaakceptowana.
As a [type of user]
I want [some goal]
so that [some benefit].
Example:
As a returning customer
I want to save my shipping address
so that I don't re-enter it every order.
Fraza "aby" jest najważniejsza — wyraża wartość, co pomaga zespołowi znaleźć lepsze rozwiązania niż to dosłownie żądane.
Given a logged-in customer with a saved address
When they reach checkout
Then the saved address is pre-filled
And they can edit it before confirming
✓ Testable and unambiguous
✓ Defines done — no "I thought you meant..."
Niezależna, Negocjowalna, Wartościowa, Mająca możliwość oszacowania, Mała, Testowalną. Historia zbyt duża do oszacowania lub zakończenia w sprincie powinna być podzielona.
Historie utrzymują zespół skoncentrowany na wartości dla użytkownika, a nie na liście zadań technicznych, i zachęcają do rozmowy zamiast narzucać rozwiązanie.
Jasne kryteria akceptacji zapobiegają najbardziej powszechnym problemom z dostawą: budowaniu czegoś, co technicznie działa, ale nie jest tym, co faktycznie było potrzebne.