„Jako klient chcę zapisać metodę płatności, aby móc szybciej dokonać zakupu następnym razem”. To jest historia użytkownika. To zdanie, a nie specyfikacja. Zespoły programistyczne Agile zapisują je na fiszkach lub karteczkach samoprzylepnych. Format ten zmusza autora do określenia roli, celu i powodu. Skupia uwagę na osobie, która faktycznie będzie korzystać z danej funkcji, a nie na schemacie bazy danych.

Historie użytkownika zostały spopularyzowane przez Kenta Becka i Rona Jeffriesa pod koniec lat 90. Są celowo niekompletne. Karta to obietnica rozmowy. Programiści, projektanci i menedżerowie produktu omawiają szczegóły. Kryteria akceptacji są dodawane później. Zbyt obszerna historia nazywana jest eposem. Zbyt niejasna historia to błąd, który tylko czeka, aby się wydarzyć.

Trzy C

• Card: historia spisana, na tyle krótka, że ​​zmieści się na papierze.
• Conversation: dyskusja, która uzupełnia luki.
• Confirmation: testy, które dowodzą, że to działa.

Dobre historie są niezależne, negocjowalne, wartościowe, godne szacunku, skromne i weryfikowalne. Skrót brzmi INVEST. To nie religia. Niektóre zespoły piszą historie jak historie o pracy: „Kiedy się spóźniam, chcę zapłacić jednym dotknięciem, żeby nie spóźnić się na pociąg”. Ten sam pomysł, inna rama.