User story (historyjka użytkownika) to krótki opis potrzeby z perspektywy użytkownika, najczęściej w formacie: „Jako [rola] chcę [funkcja], aby [korzyść]". Story nie jest specyfikacją - jest obietnicą rozmowy, a szczegóły doprecyzowuje się w dyskusji i zapisuje jako kryteria akceptacji.
To podstawowa jednostka pracy analityka w zespołach zwinnych: backlog składa się ze stories, refinement polega na ich doprecyzowywaniu, a sprint na ich dowożeniu. Dobre story spełnia kryteria INVEST: niezależne, negocjowalne, wartościowe, możliwe do oszacowania, małe, testowalne. Z tych sześciu liter w praktyce najczęściej kuleją „małe" i „testowalne".
Przykład z MediFlow: „Jako pacjent chcę dostać SMS z przypomnieniem 24 godziny przed wizytą, żeby jej nie przegapić". Kryteria akceptacji: SMS wychodzi między 8:00 a 20:00; zawiera datę, godzinę, adres przychodni i link do odwołania; nie wychodzi, jeśli wizyta została wcześniej odwołana; dla wizyt umówionych na mniej niż 24 godziny naprzód SMS idzie natychmiast po rezerwacji. Ten ostatni punkt wyszedł dopiero w rozmowie z zespołem - i właśnie po to jest format story: prowokuje rozmowę zamiast ją zastępować.
Częsta pomyłka: traktowanie szablonu jak formalności i pisanie „jako system chcę zapisać rekord do bazy". System nie jest użytkownikiem i nie ma potrzeb - jeśli nie umiesz wskazać, kto i po co czegoś chce, to sygnał, że jeszcze nie rozumiesz wymagania. Druga: rozdymanie story do mini-specyfikacji na 4 strony. Wtedy lepszy byłby use case; story ma pozostać małe i negocjowalne.