User-Story-Generator

TL;DR: Eine User Story ist eine Anforderung in einem Satz, formuliert aus Sicht des Nutzers: wer etwas braucht, was er tun will und wozu. Mit zwei, drei Akzeptanzkriterien in Angenommen / Wenn / Dann, einer Schätzung und einer MoSCoW-Priorität kann die Entwicklung ohne Rückfragen-Termin loslegen. Der Generator liefert die Vorlage, fünf fertige Beispiel-Sets, eine INVEST-Prüfung und eine CSV, die Jira als Vorgangstyp Story importiert.

Gedacht ist das Werkzeug für Gründer, Product Owner und Business-Analysten, die ein sauberes Backlog brauchen, bevor sie ein Entwicklungsteam beauftragen. Gut geschriebene Stories sind auch die schnellste Grundlage für eine Aufwandsschätzung: Planen Sie eine MVP-Entwicklung oder eine längere Zusammenarbeit im Product Engineering, schicken Sie uns das Backlog, und Sie erhalten innerhalb eines Werktags eine Einschätzung.

Der Generator arbeitet in vier Schritten, und alle Daten bleiben in Ihrem Browser:

1. Produkt. Produkt oder Release benennen, Story Points oder T-Shirt-Größen wählen und eine gemeinsame Definition of Done festlegen.
2. Set. Ein Start-Set wählen: Onlineshop, Essenslieferung, Fitness-App, SaaS-Kundenkonto oder Marktplatz mit je acht Stories, oder mit einer leeren Liste beginnen.
3. Stories. Rollen, Aktionen, Nutzen, Kriterien, Schätzungen, Prioritäten und Epics anpassen.
4. Prüfung. INVEST-Hinweise durchgehen und als CSV für Jira, DOCX, Markdown oder PDF exportieren.

Eine KI-Generierung gibt es in dieser Version bewusst nicht. Sie gehen von einer Vorlage oder einem Set aus und schreiben es um, damit die Stories Ihr Produkt beschreiben und keinen Allerweltsshop.

Wie sieht eine gute User Story aus?

Eine gute User Story nennt eine konkrete Rolle, genau eine Aktion und einen Nutzen, den Sie auch vor dem Budgetverantwortlichen vertreten können: „Als [Rolle] möchte ich [Aktion], damit [Nutzen]“. Ein vollständiges Beispiel für einen Onlineshop:

Story: Als Stammkundin möchte ich eine frühere Bestellung mit einem Klick erneut aufgeben, damit ich den Warenkorb nicht neu zusammenstellen muss.

• Angenommen, ich bin angemeldet und habe eine abgeschlossene Bestellung, wenn ich bei ihr auf „Erneut bestellen“ klicke, dann landen alle verfügbaren Artikel in derselben Menge im Warenkorb.
• Angenommen, ein Artikel aus dieser Bestellung ist ausverkauft, wenn ich auf „Erneut bestellen“ klicke, dann werden die übrigen Artikel übernommen und ich sehe, welcher fehlt.
• Angenommen, mein Warenkorb ist bereits gefüllt, wenn ich erneut bestelle, dann werden die Artikel ergänzt und nichts wird überschrieben.

Schätzung: 3 Story Points (M). Priorität: Should. Epic: Bestellungen.

Buttons, Tabellen und Schnittstellen stehen bewusst nicht in der Story: Das entscheidet das Team. Lässt sich der „damit“-Teil nicht ausfüllen, ist die Funktion vermutlich verzichtbar.

Wie formuliert man Akzeptanzkriterien in Angenommen / Wenn / Dann?

Pro Kriterium ein Szenario: Angenommen beschreibt den Zustand vor der Aktion, Wenn die Aktion selbst, Dann ein Ergebnis, das jemand ohne Rückfrage prüfen kann. In manchen Teams heißt das Muster auch Gegeben / Wenn / Dann oder schlicht Given / When / Then, gemeint ist dasselbe. Beginnen Sie mit dem Normalfall und ergänzen Sie, was im Betrieb typischerweise schiefgeht: leere Daten, Fehler, fehlende Berechtigung, Verbindungsabbruch. Drei bis fünf Kriterien sind ein guter Richtwert; brauchen Sie mehr als sechs, stecken meist zwei Stories in einer.

Akzeptanzkriterien sind nicht die Definition of Done. Kriterien gehören zu einer einzelnen Story, die Definition of Done gilt für alle („Code-Review erledigt, Tests grün, auf Staging ausgerollt“). Die QA kann jede Angenommen-Wenn-Dann-Zeile direkt in einen Testfall übernehmen.

Was bedeutet INVEST und was prüft der Generator?

INVEST ist eine Qualitätsprüfung mit sechs Kriterien. Der Generator markiert, was sich automatisch erkennen lässt; den Rest klären Sie im Refinement.

Wie schätzt und priorisiert man User Stories?

Story Points auf der Skala 1, 2, 3, 5, 8 vergleichen Stories untereinander; Stunden sind das nicht. T-Shirt-Größen gehen für die erste Runde schneller, der Generator speichert sie als Punkte (XS = 1, S = 2, M = 3, L = 5, XL = 8), damit die Jira-Spalte numerisch bleibt.

MoSCoW teilt das Backlog in Must, Should, Could und Won’t (diesmal nicht). Halten Sie die Must-Gruppe für das erste Release so klein, dass sie allein schon etwas Nutzbares ergibt. Won’t dokumentiert, worauf Sie bewusst verzichten.

Wie importiert man User Stories in Jira?

Laden Sie „CSV für Jira“ herunter, öffnen Sie in Jira System → Import aus externem System → CSV und ordnen Sie die Spalten zu. Eine Zeile entspricht einer Story:

• Summary: die Aktion, kurz genug für eine Board-Karte;
• Description: der ganze Satz „Als … möchte ich … damit …“ plus nummerierte Akzeptanzkriterien;
• Issue Type: immer Story;
• Story Points: 1 bis 8;
• Epic Link: der Epic-Name; Epics vorher anlegen oder vorhandene Schlüssel nutzen;
• Labels: die MoSCoW-Priorität (moscow-must, moscow-should …) und bei T-Shirt-Schätzung die Größe.

In teamverwalteten Projekten ordnen Sie das Epic dem Feld Parent statt Epic Link zu.

Wie hängen User Stories mit PRD und Lastenheft zusammen?

Stories beschreiben Verhalten, die Dokumente drumherum den Rahmen. Ziele, Scope, Risiken und nichtfunktionale Anforderungen gehören in die Produktanforderungen, die Sie mit der PRD-Vorlage aufsetzen. Dort halten Sie auch fest, welche DSGVO-Konformität Sie vom Dienstleister erwarten, denn das ist keine einzelne Story. Vergeben Sie die Entwicklung extern, hängen Sie das Backlog an ein Lastenheft für die Angebotsanfrage und vergleichen Sie die Antworten in der Bewertungsmatrix für Dienstleister. Angebote auf dieselben Stories lassen sich weit besser vergleichen als Schätzungen auf ein vages Briefing.

Häufige Fragen

Verwandte Tools