So schreiben Sie Nutzerstories (mit Beispielen und Akzeptanzkriterien)

Eine Nutzerstory ist eine kurze Beschreibung einer Funktion aus Sicht des Nutzers: „Als [Art des Nutzers] möchte ich [Ziel], damit [Grund].“ Darunter schreiben Sie Akzeptanzkriterien, einige konkrete Bedingungen, die erfüllt sein müssen, damit die Story als fertig gilt. Halten Sie jede Story klein genug, um sie in einem Durchgang zu bauen und zu testen, und formulieren Sie die Kriterien so, dass sie jeder überprüfen kann.

Nutzerstories wurden durch agile Softwareteams bekannt, sind aber genauso nützlich, wenn Sie allein mit einem KI-App-Builder bauen. Eine gute Story ist ein guter Prompt.

Das Format

Eine Nutzerstory hat drei Teile:

Als [wer] möchte ich [was] damit [warum].

Wer ist eine bestimmte Art von Nutzer: ein Erstbesucher, ein zahlendes Mitglied, eine Empfangskraft in einer Klinik, ein Administrator. Nicht „der Nutzer“.
Was ist das, was er tun möchte, mit seinen eigenen Worten. Nicht, wie der Bildschirm funktioniert.
Warum ist das Ergebnis, das ihm wichtig ist. Dieser Teil wird oft übersprungen, und er verhindert, dass Sie das Falsche bauen.

Beispiel:

Als Fitnessstudio-Mitglied möchte ich eine Kursbuchung von meinem Handy aus stornieren, damit jemand auf der Warteliste meinen Platz übernehmen kann und mir keine Gebühr für Nichterscheinen berechnet wird.

Das „Warum“ verrät zwei Dinge, die das „Was“ nicht sagte: Es muss auf dem Handy funktionieren, und die Warteliste sowie die Gebührenregeln spielen eine Rolle.

Akzeptanzkriterien

Eine Story sagt, was gewünscht ist. Akzeptanzkriterien sagen, wann es fertig ist. Sie sollten so konkret sein, dass sich zwei Personen einig wären, ob jedes davon erfüllt ist.

Eine verbreitete Schreibweise ist Given / When / Then:

Gegeben eine Ausgangssituation
Wenn der Nutzer etwas tut
Dann ist dies das Ergebnis

Für die Buchungs-Story im Fitnessstudio:

Gegeben ich habe eine Buchung, die mehr als 12 Stunden entfernt ist, wenn ich auf Stornieren tippe und bestätige, dann wird die Buchung entfernt und ich sehe „Buchung storniert“.
Gegeben ich storniere eine Buchung und der Kurs hat eine Warteliste, wenn die Stornierung gespeichert ist, dann bekommt die erste Person auf der Warteliste den Platz und eine E-Mail.
Gegeben eine Buchung liegt weniger als 12 Stunden entfernt, wenn ich auf Stornieren tippe, dann sehe ich, dass eine Gebühr für späte Stornierung anfällt, bevor ich bestätige.
Gegeben ich bin auf einem Bildschirm in Handybreite, dann ist der Stornieren-Button ohne seitliches Scrollen sichtbar.

Eine einfache Checkliste funktioniert ebenso, solange jeder Punkt testbar ist. „Stornieren ist einfach“ ist nicht testbar. „Stornieren braucht höchstens zwei Tipps aus der Buchungsliste“ schon.

Schritt für Schritt: eine gute Story schreiben

Schritt 1: Bei einem echten Nutzer und einem echten Problem anfangen

Wählen Sie eine Art von Nutzer und etwas, womit er heute zu kämpfen hat. Wenn Sie Kundengespräche geführt haben, verwenden Sie deren Worte. „Ich vergesse immer zu stornieren und werde belastet“ ist ein besserer Ausgangspunkt als „Stornierungsfunktion hinzufügen“.

Schritt 2: Die Ein-Zeilen-Story schreiben

Füllen Sie die Vorlage aus. Wenn Sie kein überzeugendes „damit“ formulieren können, fragen Sie, ob die Funktion überhaupt nötig ist.

Schritt 3: Drei bis sechs Akzeptanzkriterien ergänzen

Decken Sie zuerst den wichtigsten Erfolgsfall ab, dann die relevanten Abweichungen: eine andere Rolle, einen leeren Zustand, eine Grenze, einen Fehler. Wenn Sie mehr als sechs schreiben, ist die Story wahrscheinlich zu groß.

Schritt 4: Notieren, was nicht dazugehört

Eine Zeile spart viel Hin und Her: „Nicht enthalten: Rückerstattungen für bezahlte Kurse; Administratoren, die für Mitglieder stornieren.“ Das verhindert, dass die Story während des Bauens wächst.

Schritt 5: Gegen INVEST prüfen

INVEST ist eine verbreitete Checkliste für gute Stories. Eine Story sollte sein:

Buchstabe	Bedeutet	Schneller Test
I	Independent (unabhängig)	Kann gebaut werden, ohne auf eine andere Story zu warten
N	Negotiable (verhandelbar)	Beschreibt den Bedarf, nicht ein festes Design
V	Valuable (wertvoll)	Ein Nutzer würde es bemerken, wenn es ausgeliefert wird
E	Estimable (schätzbar)	Sie können grob abschätzen, wie groß sie ist
S	Small (klein)	In einer Sitzung gebaut und getestet
T	Testable (testbar)	Jedes Akzeptanzkriterium lässt sich prüfen

Sie müssen nicht jede Story bewerten. Am nützlichsten ist INVEST, wenn sich eine Story falsch anfühlt und Sie wissen wollen, warum.

Gute und schlechte Beispiele

Schwache Story	Problem	Bessere Story
Als Nutzer möchte ich ein Dashboard.	Kein konkreter Nutzer, kein Grund, nicht testbar	Als Shop-Inhaber möchte ich die heutigen Bestellungen und den Umsatz auf einem Bildschirm sehen, damit ich auf einen Blick erkenne, ob der Tag gut läuft.
Als Administrator möchte ich, dass die Datenbank eine Statusspalte hat.	Beschreibt die Umsetzung, nicht einen Bedarf	Als Administrator möchte ich Bestellungen als versandt markieren, damit Kunden nicht mehr per E-Mail nachfragen, wo ihre Ware ist.
Als Kunde möchte ich mein Konto verwalten.	Zu groß: deckt viele Funktionen ab	Als Kunde möchte ich meine E-Mail-Adresse ändern, damit Belege an mein neues Postfach gehen.
Als Besucher möchte ich, dass die Seite schnell ist.	Keine Story, sondern eine Eigenschaft, die alle brauchen	Als Kriterium in jede Story aufnehmen oder als eigenes Leistungsziel formulieren.

Wie Sie eine zu große Story aufteilen

Zu große Stories sind der Grund, warum Projekte stocken. Übliche Wege zum Aufteilen:

Nach Nutzerrolle. Mitglieder stornieren ihre eigenen Buchungen; Mitarbeiter stornieren beliebige.
Nach Schritt im Ablauf. Kurse durchsuchen; einen Kurs buchen; eine Erinnerung erhalten.
Zuerst der einfache Fall. Einen kostenlosen Kurs jetzt stornieren; Gebühren und Rückerstattungen in einer späteren Story behandeln.
Nach Datenvariation. Zuerst einen Standort unterstützen, später mehrere.
Erfolgsfall zuerst, dann Fehler. Erst funktionierend bauen, dann die Behandlung für volle Kurse, abgelaufene Pässe und so weiter ergänzen.

Jedes Teilstück sollte trotzdem etwas sein, das ein Nutzer verwenden und bemerken kann.

Nutzerstories als Prompts verwenden

Eine Nutzerstory mit Akzeptanzkriterien ist einem guten Prompt für einen KI-App-Builder sehr nah. Sie liefert der KI das Wer, das Was, das Warum und eine Definition von fertig. Senden Sie eine Story pro Nachricht:

Als Fitnessstudio-Mitglied möchte ich eine Kursbuchung von meinem Handy aus stornieren, damit jemand auf der Warteliste meinen Platz übernehmen kann. Akzeptanzkriterien:

Stornieren steht bei jeder Buchung unter Meine Buchungen, mit einem Bestätigungsschritt.

Bei einer Stornierung mehr als 12 Stunden vor dem Kurs wird die Buchung einfach entfernt.

Weniger als 12 Stunden vorher: Vor der Bestätigung „Es fällt eine Gebühr von 5 $ für späte Stornierung an“ anzeigen und die Gebühr an der Buchung speichern.

Hat der Kurs eine Warteliste, erhält die erste Person den Platz und eine E-Mail.

Funktioniert auf einem Bildschirm in Handybreite. Nicht enthalten: Rückerstattungen, Stornierungen durch Mitarbeiter für Mitglieder. Baue das, prüfe dann jedes Kriterium in der Vorschau und sag mir, welche bestehen.

Sie können die KI auch bitten, aus einer groben Idee Stories zu entwerfen, und diese dann selbst bearbeiten:

Hier ist meine App-Idee: [zwei oder drei Sätze]. Schreibe die Nutzerstories für eine erste Version, gruppiert nach Nutzertyp, jede mit 3 bis 5 Given/When/Then-Akzeptanzkriterien. Markiere, welche für den Start unverzichtbar sind und welche warten können.

Lesen und bearbeiten Sie das Ergebnis immer selbst. Die KI kennt Ihre Nutzer nicht; Sie kennen sie.

Die Akzeptanzkriterien dienen außerdem als Ihr Testplan. Wenn die Story gebaut ist, gehen Sie jedes Kriterium selbst durch. Unser Leitfaden zum Testen Ihrer App vor dem Start baut darauf auf.

Wo Nutzerstories zu anderen Dokumenten passen

Ein Product Requirements Document beschreibt das ganze Produkt: das Problem, die Nutzer, den Umfang. Nutzerstories sind die detaillierten Bausteine darin. Siehe wie Sie ein PRD mit KI schreiben.
Ein Fehlerbericht beschreibt etwas, das gegen eine bereits gebaute Story kaputt ist. Siehe wie Sie einen guten Fehlerbericht schreiben.
Ein MVP ist die kleinste Menge an Stories, die den Kernnutzen liefert. Siehe was ist ein MVP.

Häufige Fehler

„Als Nutzer …“ Zu vage. Nennen Sie die konkrete Art von Nutzer.
Das „damit“ weglassen. Ohne Grund können Sie keine sinnvollen Abwägungen treffen.
Die Lösung statt des Bedarfs schreiben. „Ich möchte ein Dropdown“ legt ein Design fest, bevor jemand darüber nachgedacht hat.
Kriterien, die sich nicht testen lassen. „Einfach“, „schnell“ und „intuitiv“ sind Wünsche, keine Kriterien.
Stories, die eigentlich Epics sind. „Mein Konto verwalten“ sind zehn Stories.
Alle Stories im Voraus schreiben. Schreiben Sie die nächsten paar im Detail; die übrigen halten Sie als Einzeiler, bis Sie dort ankommen.

Stories in Mythex

In Mythex ist der Modus Plan ein guter Ort, um eine Idee in Stories zu verwandeln: Der Agent bespricht den Ansatz, bevor er etwas bearbeitet. Ist eine Story fertig, wechseln Sie zu Build und fügen sie ein, eine Story pro Nachricht. Danach kann /test die Vorschau durchklicken und den Ablauf prüfen, und Sie können jede Antwort mit Zu diesem Punkt zurückkehren zurücksetzen, falls sie in die falsche Richtung ging. Siehe wirksame Prompts in der Dokumentation und unseren Leitfaden zum Schreiben von Prompts für KI-App-Builder.

Checkliste für Nutzerstories

Nennt eine konkrete Art von Nutzer
Beschreibt einen Bedarf, kein Design
Enthält ein echtes „damit“ als Grund
Hat drei bis sechs testbare Akzeptanzkriterien
Deckt mindestens einen Randfall oder Fehler ab
Nennt, was nicht dazugehört
Klein genug, um sie in einem Durchgang zu bauen und zu testen
Kriterien nach dem Bauen einzeln geprüft

Fragen

Wie ist eine Nutzerstory aufgebaut?

Die gängige Vorlage lautet: Als [Art des Nutzers] möchte ich [ein Ziel], damit [ein Grund]. Darauf folgen die Akzeptanzkriterien, eine kurze Liste von Bedingungen, die erfüllt sein müssen, damit die Story als fertig gilt.

Was sind Akzeptanzkriterien?

Akzeptanzkriterien sind konkrete, testbare Bedingungen, die festlegen, wann eine Nutzerstory abgeschlossen ist. Sie werden oft in der Form Given / When / Then geschrieben: Gegeben eine Ausgangssituation, wenn der Nutzer etwas tut, dann tritt ein bestimmtes Ergebnis ein.

Wie groß sollte eine Nutzerstory sein?

Klein genug, um sie in einer Sitzung zu bauen und zu testen, und trotzdem für sich genommen wertvoll. Hat eine Story mehr als fünf oder sechs Akzeptanzkriterien oder umfasst sie mehrere Bildschirme, teilen Sie sie nach Nutzerrolle, nach Schritt im Ablauf oder zuerst nach dem einfachen Fall und die Randfälle später auf.

Sind Nutzerstories beim Bauen mit KI hilfreich?

Ja. Eine Nutzerstory mit Akzeptanzkriterien ist nahezu ein idealer Prompt: Sie sagt, für wen die Funktion gedacht ist, was diese Person braucht und genau, wie man prüft, ob es funktioniert. Eine Story pro Nachricht hält außerdem KI-Änderungen klein und leicht testbar.