„Als Kunde möchte ich meine Zahlungsmethode speichern, um beim nächsten Mal schneller bezahlen zu können.“ Das ist eine User Story. Es ist ein Satz, keine Spezifikation. Agile Softwareteams schreiben sie auf Karteikarten oder Haftnotizen. Dieses Format zwingt den Verfasser, eine Rolle, ein Ziel und einen Grund zu benennen. So bleibt der Fokus auf der Person, die die Funktion tatsächlich nutzen wird, und nicht auf dem Datenbankschema.

User Stories wurden Ende der 1990er-Jahre von Kent Beck und Ron Jeffries bekannt gemacht. Sie sind bewusst unvollständig. Die Karte ist ein Versprechen für ein Gespräch. Entwickler, Designer und Produktmanager besprechen die Details. Akzeptanzkriterien werden später hinzugefügt. Eine zu umfangreiche Story wird als Epic bezeichnet. Eine zu vage Story birgt das Risiko eines Fehlers.

Drei Cs

• Card: die schriftliche Geschichte, kurz genug, um auf ein Blatt Papier zu passen.
• Conversation: die Diskussion, die die Lücken füllt.
• Confirmation: die Tests, die beweisen, dass es funktioniert.

Gute Geschichten sind unabhängig, verhandelbar, wertvoll, anerkennenswert, kurz und überprüfbar. Das Akronym lautet INVEST. Es ist keine Glaubenslehre. Manche Teams formulieren Geschichten wie Job-Stories: „Wenn ich in Zeitnot bin, möchte ich mit einer einzigen Berührung bezahlen, damit ich meinen Zug nicht verpasse.“ Gleiche Idee, anderer Rahmen.