User Story
Requirements EngineeringEine kurze Beschreibung einer Anforderung aus Sicht des Nutzers: wer etwas braucht, was und wozu. Sie ist bewusst knapp – als Einladung zum Gespräch, nicht als Ersatz dafür.
Die bekannte Form lautet: Als Rolle möchte ich ein Ziel erreichen, um einen Nutzen zu haben. „Als Stammkundin möchte ich meine letzte Bestellung wiederholen, um nicht alles neu suchen zu müssen.“ Der dritte Teil ist der wichtigste und wird am häufigsten weggelassen – dabei entscheidet das Wozu, ob die Lösung die richtige ist.
Eine Story besteht aus mehr als dem Satz. Dazu gehören das Gespräch, in dem sie geklärt wird, und die Akzeptanzkriterien, an denen man sie prüft. Als Merkhilfe für gute Storys dient INVEST: unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar.
Der häufigste Fehler ist die verkleidete Aufgabe: „Als Entwickler möchte ich die Datenbank umstellen.“ Das ist keine Nutzeranforderung, sondern Arbeit. Storys beschreiben, was sich für einen Menschen ändert. Technische Arbeiten gehören als Aufgaben unter die Story, deren Nutzen sie ermöglichen.
In Workshops lasse ich Auftraggeber ihre Anforderungen zuerst als Storys formulieren – und höre beim Wozu genau hin. Erstaunlich oft stellt sich heraus, dass hinter drei gewünschten Funktionen derselbe Nutzen steckt, der sich mit einer einzigen, einfacheren Lösung erreichen lässt. Das spart mehr Budget als jede Verhandlung über Tagessätze.
Wie groß darf eine User Story sein?
So klein, dass sie in wenigen Tagen umgesetzt und innerhalb eines Sprints abgeschlossen werden kann. Größere Vorhaben heißen Epic und werden in mehrere Storys zerlegt.
Ersetzen User Storys das Lastenheft?
In agilen Projekten weitgehend, ja – zusammen mit Akzeptanzkriterien und Qualitätsanforderungen. Bei Ausschreibungen und Festpreisen braucht es zusätzlich einen Rahmen, der Ziele, Umfang und Abgrenzung beschreibt.