Was ist eine User Story?

Eine User Story ist eine kurze Beschreibung einer Anforderung aus der Sicht derjenigen, die eine Software später benutzen. Sie folgt meist dem Muster „Als [Rolle] möchte ich [Ziel], damit [Nutzen]“. Statt technischer Details hält sie fest, wer etwas braucht und warum. Die Einzelheiten klären Fachbereich und Entwicklung im Gespräch.

User Stories sind das übliche Format, mit dem in agilen Projekten Anforderungen gesammelt und sortiert werden. Sie sind bewusst knapp – und gerade deshalb verständlich für alle Beteiligten, auch ohne IT-Kenntnisse.

Aufbau einer User Story

Die bekannte Satzschablone hat drei Teile:

• Rolle: Wer braucht die Funktion? Zum Beispiel „Disponentin“, „Außendienstmitarbeiter“ oder „Kunde im Portal“.
• Ziel: Was will diese Person erreichen? Formuliert als Tätigkeit, nicht als Bildschirmelement.
• Nutzen: Warum ist das wichtig? Dieser Teil wird am häufigsten weggelassen und ist oft der wertvollste, weil er bessere Lösungen zulässt.

Ein Beispiel: „Als Disponentin möchte ich sehen, welche Monteure morgen noch freie Zeit haben, damit ich Notfalleinsätze ohne Rückrufe einplanen kann.“

Zu jeder Story gehören Akzeptanzkriterien. Sie legen fest, wann die Anforderung erfüllt ist, etwa: „Die Ansicht zeigt freie Zeitfenster ab 30 Minuten“ oder „Urlaub und Krankheit sind berücksichtigt“. Ohne diese Kriterien weiß niemand sicher, wann die Arbeit fertig ist.

So arbeitet ein Team mit User Stories

Ron Jeffries hat die Arbeitsweise mit drei Begriffen beschrieben, den „drei C“:

1. Card: Die Story passt auf eine Karteikarte. Sie ist eine Erinnerung an ein Gespräch, keine vollständige Spezifikation.
2. Conversation: Fachbereich und Entwicklung besprechen die Details, bevor gebaut wird. Hier entstehen Fragen wie „Was passiert, wenn zwei Disponenten gleichzeitig planen?“
3. Confirmation: Die Akzeptanzkriterien bestätigen am Ende, dass die Story umgesetzt ist.

Als Qualitätsprüfung hat sich die Merkhilfe INVEST durchgesetzt: Eine gute Story ist unabhängig (Independent), verhandelbar (Negotiable), wertvoll (Valuable), schätzbar (Estimable), klein (Small) und testbar (Testable). Zu große Stories, oft „Epics“ genannt, werden in mehrere kleine zerlegt, bevor ein Team sie in einen Sprint nimmt.

Beispiele aus dem Mittelstand

• Großhandel, Kundenportal: „Als Einkäufer eines Stammkunden möchte ich eine frühere Bestellung mit einem Klick wiederholen, damit ich Standardware nicht jedes Mal neu zusammensuchen muss.“
• Bauunternehmen, Mängelmanagement: „Als Bauleiter möchte ich einen Mangel mit Foto direkt auf der Baustelle erfassen, damit der zuständige Subunternehmer ihn noch am selben Tag sieht.“
• Buchhaltung, Belegeingang: „Als Buchhalterin möchte ich Rechnungen ohne Bestellnummer gesammelt sehen, damit ich sie vor der Zahlungsfrist klären kann.“

Keine dieser Stories schreibt vor, wie die Lösung aussieht. Ob die Bestellung per Knopf, per Vorlage oder per Vorschlag wiederholt wird, entscheidet das Team im Gespräch – mit dem Nutzen als Maßstab.

User Story, Lastenheft und Use Case

• Das Lastenheft beschreibt alle Anforderungen des Auftraggebers als Gesamtdokument. User Stories können darin stehen oder daraus abgeleitet werden.
• Das Pflichtenheft ist die Antwort des Auftragnehmers: wie er die Anforderungen umsetzt. Es ist deutlich technischer.
• Ein Use Case beschreibt einen Ablauf ausführlich, Schritt für Schritt, einschließlich Sonderfällen. Er ist länger und formaler als eine Story.
• Eine Aufgabe („Datenbankfeld anlegen“) ist die technische Arbeit, die aus einer Story folgt. Sie ist selbst keine Story, weil sie keinen Nutzen für eine Person beschreibt.

Typische Fehler

• „Als Nutzer möchte ich …“ Die Rolle ist so allgemein, dass sie nichts aussagt. Wer genau? Neue Kunden haben andere Bedürfnisse als die Sachbearbeitung im Haus.
• Technik statt Ziel. „Als Admin möchte ich eine REST-Schnittstelle“ ist eine Lösung, keine Anforderung. Dahinter steckt meist ein Bedarf wie „Bestellungen sollen ohne Abtippen in der Buchhaltung ankommen“.
• Fehlender Nutzen. Ohne „damit“ lässt sich nicht priorisieren. Zwei Stories ohne Begründung wirken gleich wichtig.
• Keine Akzeptanzkriterien. Streit am Ende des Sprints, ob etwas fertig ist, lässt sich fast immer darauf zurückführen.
• Stories als Vertragsersatz. Eine Sammlung von Stories regelt weder Budget noch Haftung. Für Festpreisprojekte braucht es zusätzlich einen klaren Leistungsrahmen.

In der Praxis: vom Satz zur laufenden Funktion

Viele Projekte, die wir als Individualsoftware umsetzen, beginnen mit einem Workshop, in dem wir mit Ihrem Team die ersten User Stories schreiben. Das geht schneller als ein langes Anforderungsdokument und macht früh sichtbar, welche Funktionen den größten Nutzen bringen. Die wichtigsten Stories setzen wir zuerst um, zeigen sie an lauffähiger Software und sortieren den Rest danach neu. Wie Sie Anforderungen in einem Dokument festhalten, wenn ein Auftrag das verlangt, zeigt der Beitrag Lastenheft für Software. Geht es um ein Portal oder ein internes Tool im Browser, lesen Sie weiter unter Web-Anwendungen.

Häufige Fragen

Wer schreibt User Stories?

In Scrum verantwortet der Product Owner das Product Backlog und damit auch die Stories darin. In der Praxis entstehen gute Stories gemeinsam: Der Fachbereich bringt den Bedarf ein, das Entwicklungsteam fragt nach und schätzt den Aufwand.

Wie groß darf eine User Story sein?

So groß, dass ein Team sie innerhalb eines Sprints fertigstellen kann, besser in wenigen Tagen. Alles darüber sollte in kleinere Stories zerlegt werden.

Was sind Story Points?

Eine relative Schätzgröße für den Aufwand einer Story. Sie vergleicht Stories untereinander, statt Stunden vorherzusagen, und hilft dem Team, seine Kapazität pro Sprint einzuschätzen.

Müssen User Stories immer dem Satzmuster folgen?

Nein. Das Muster ist eine Hilfe, keine Pflicht. Wichtig ist, dass Rolle, Ziel und Nutzen erkennbar sind und Akzeptanzkriterien festhalten, wann die Story erfüllt ist.