User Stories schreiben: Anforderungen, die Entwickler und Auftraggeber gleich verstehen

Eine User Story beschreibt eine Anforderung an eine Software aus Sicht der Person, die sie nutzt. Das Standardformat lautet: «Als [Rolle] möchte ich [Ziel], damit [Nutzen].» Zusammen mit Akzeptanzkriterien, die festlegen, wann die Story erfüllt ist, entsteht eine Anforderung, die Auftraggeber und Entwickler gleich verstehen. Genau das ist der Zweck: nicht ein schönes Dokument, sondern eine gemeinsame Sprache.

User Stories stammen aus der agilen Softwareentwicklung, sind aber längst nicht nur für Scrum-Teams nützlich. Jedes KMU, das eine Web-App, ein Kundenportal oder ein MVP in Auftrag gibt, profitiert davon, Anforderungen so zu formulieren. Sie zwingen zur Klarheit darüber, wer etwas braucht und warum, und sie machen sichtbar, welche Anforderungen wichtig sind und welche warten können. Dieser Artikel zeigt das Format, die häufigsten Fehler und zehn ausgearbeitete Beispiele.

Das Format: drei Teile, ein Satz

Jede User Story besteht aus drei Teilen:

Der dritte Teil wird am häufigsten weggelassen, und er ist der wertvollste. Der Nutzen erklärt dem Entwicklungsteam, worauf es ankommt, und erlaubt bessere Lösungen. Wenn die Kundin «nicht anrufen muss», ist eine Buchung um Mitternacht wichtiger als eine besonders elegante Kalenderansicht.

Die Rolle sollte so konkret wie möglich sein. «Als Benutzer» sagt nichts. «Als Neukundin», «als Stammkunde» oder «als Mitarbeiterin am Empfang» beschreiben Menschen mit unterschiedlichen Bedürfnissen. Wer die Rollen sauber kennen will, beginnt mit kurzen Personas.

Akzeptanzkriterien: wann eine Story erfüllt ist

Eine Story ohne Akzeptanzkriterien ist ein Wunsch. Erst die Kriterien machen sie zu einer Abmachung. Ein bewährtes Format ist «Gegeben … wenn … dann …»:

Story: Als Kundin möchte ich einen Termin online buchen, damit ich nicht während der Öffnungszeiten anrufen muss.

Akzeptanzkriterien:

• Gegeben ein freier Termin, wenn ich Datum, Uhrzeit und Leistung wähle und meine Kontaktdaten eingebe, dann erhalte ich eine Bestätigung auf dem Bildschirm und per E-Mail.
• Gegeben ein bereits belegter Termin, wenn ich ihn wählen will, dann ist er nicht auswählbar.
• Gegeben eine fehlende E-Mail-Adresse, wenn ich absende, dann sehe ich einen verständlichen Hinweis beim Feld.

Gute Akzeptanzkriterien beschreiben Verhalten, keine Gestaltung. «Der Button ist blau» gehört nicht hinein. «Ein belegter Termin ist nicht auswählbar» schon. Sie decken neben dem Normalfall auch die wichtigsten Fehlerfälle ab, denn genau dort entstehen später die Diskussionen.

Zehn Beispiel-Stories für ein fiktives MVP

Das folgende Beispiel ist erfunden, aber realistisch. Ein Coiffeursalon mit drei Standorten möchte Online-Buchungen anbieten. Das Team arbeitet am Kunden, nicht am Computer, und soll neue Buchungen sofort aufs Handy bekommen. Daraus ergeben sich drei Rollen: Kundin, Mitarbeiterin im Salon und Inhaberin.

Diese Liste ist nicht vollständig, und das ist Absicht. Sie enthält genau so viel, wie es braucht, um zu prüfen, ob Kundinnen online buchen und ob das Team die Buchungen zuverlässig erhält. Alles Weitere, etwa Anzahlungen, Gutscheine oder ein Treueprogramm, wartet, bis der erste Teil funktioniert.

Wie sich die Push-Benachrichtigung aus Story 4 in der Praxis anfühlt, zeigt ein Projekt aus der Gastronomie: Bei Han Kitchen löst jede neue Reservation sofort einen Push auf dem Handy aus, und der Gast lässt sich mit einem Tipp per WhatsApp bestätigen, ohne Kosten pro Nachricht. Warum dafür keine App aus dem App Store nötig ist, erklärt unser Artikel PWA statt App-Store-App.

Vom Backlog zum MVP-Umfang

Die zehn Stories sind priorisiert in «muss», «soll» und «kann». Diese Einteilung ist das Werkzeug, mit dem sich ein Umfang schneiden lässt, der in ein festes Budget passt. Ein MVP enthält nur, was nötig ist, um die zentrale Annahme zu prüfen. Im Beispiel lautet sie: Kundinnen buchen online, und das Team reagiert zuverlässig darauf.

Daraus ergibt sich ein Schnitt in drei Stufen:

Die Stories 1 bis 5 bilden einen vollständigen User Flow von der Suche bis zur Benachrichtigung. Genau dieser durchgehende Ablauf ist der Kern eines Prototyps oder MVP, wie wir ihn bei DLM Digital ab CHF 10'000 bauen: bedienbar, an echten Nutzern prüfbar und ohne Funktionen, deren Nutzen noch niemand bestätigt hat. Was in diesem Rahmen enthalten ist und was bewusst nicht, beschreibt die Seite Prototyp und Validierung.

Die häufigsten Fehler

In Projekten, die mit User Stories arbeiten, sehen wir immer wieder dieselben Schwächen:

• Technik statt Nutzen. «Als Entwickler möchte ich eine Datenbanktabelle für Termine» ist keine User Story, sondern eine Aufgabe. Stories beschreiben, was eine Person erreichen will.
• Zu grosse Stories. «Als Kundin möchte ich alles rund um meine Termine verwalten» enthält ein Dutzend Stories. Grosse Stories, oft Epics genannt, werden geteilt, bis jede einzeln umsetzbar und testbar ist.
• Fehlender Nutzen. Ohne den «damit»-Teil fehlt die Begründung, und mit ihr die Grundlage für Priorisierung und bessere Lösungen.
• Keine Fehlerfälle. Akzeptanzkriterien, die nur den Normalfall beschreiben, lassen offen, was bei falschen Eingaben, Doppelbuchungen oder Ausfällen passiert.
• Alle Stories sind «muss». Wenn alles gleich wichtig ist, ist nichts priorisiert. Im Beispiel oben ist die Hälfte «muss», und für ein MVP ist das bereits die Obergrenze; je weiter der Backlog wächst, desto grösser sollte der Anteil an «soll» und «kann» werden.

User Stories oder Lastenheft?

User Stories und Lastenheft schliessen sich nicht aus, sie lösen unterschiedliche Aufgaben. Das klassische Lastenheft beschreibt alle Anforderungen eines Projekts vorab und eignet sich für Vorhaben mit festem, klar umrissenem Umfang. User Stories beschreiben Anforderungen einzeln, werden priorisiert und mit jedem Test verfeinert. Für ein neues Produkt, dessen Erfolg noch nicht feststeht, sind sie meist die bessere Wahl.

In der Praxis hat sich eine Kombination bewährt: ein kurzes Lastenheft mit Ziel, Rahmenbedingungen und Abgrenzung, darunter ein priorisierter Backlog aus User Stories. Aufbau und Vorlage für den ersten Teil finden Sie in unserem Artikel Lastenheft und Pflichtenheft für Software.

So entstehen gute Stories im Projekt

User Stories schreibt man nicht allein am Schreibtisch. Die besten entstehen im Gespräch zwischen den Menschen, die den Ablauf kennen, und denen, die ihn umsetzen. In einer kurzen Discovery-Phase klären beide Seiten in wenigen Workshops die Rollen, den Kernablauf und die zentrale Annahme. Danach entstehen die Stories meist innerhalb weniger Stunden, weil die eigentlichen Fragen bereits beantwortet sind.

Bei DLM Digital beginnt jedes Prototyp- und MVP-Projekt so. Am Ende der Klärung steht ein priorisierter Backlog, ein klarer Schnitt für die erste Stufe und ein Preis, der auf diesem Schnitt beruht und nicht auf einer Schätzung ins Blaue.

Fazit

User Stories sind ein einfaches Werkzeug mit grosser Wirkung. Ein Satz mit Rolle, Ziel und Nutzen, ergänzt um prüfbare Akzeptanzkriterien, schafft eine Sprache, die Auftraggeber und Entwickler gleich verstehen. Wer seine Anforderungen so formuliert und konsequent priorisiert, kann einen MVP-Umfang schneiden, der in ein festes Budget passt, und erfährt früh, ob die Idee trägt. Die zehn Beispiele oben lassen sich als Vorlage für das eigene Vorhaben übernehmen: Rollen austauschen, Ablauf anpassen, Prioritäten ehrlich setzen.