User Story aus einem Interview: Vorlage und Akzeptanzkriterien
Leiten Sie eine User Story aus einem Kundeninterview ab: Bedarf erkennen, Quelle sichern und überprüfbare Akzeptanzkriterien ergänzen. Mit Beispiel und Vorlage.
Eine User Story beschreibt den Nutzen, nicht die Schaltfläche
Eine User Story beschreibt kurz ein gewünschtes Ergebnis aus Sicht einer Person, die das Produkt nutzt. Üblich ist: „Als [Rolle] möchte ich [Handlung], damit [Nutzen].“ Das eröffnet das Gespräch über den Bedarf. Anforderungen und Prüfung bleiben eigene Schritte.
„Fügt eine grüne Schaltfläche hinzu“ schlägt eine Lösung vor. Finden Sie für die Story heraus, was die Person erreichen will und warum der bisherige Ablauf sie behindert. Bewahren Sie die Aussage zur Prüfung Ihrer Deutung auf.
Als Nutzer möchte ich eine große Export-Schaltfläche, damit sie leicht zu bedienen ist.
Als Projektkoordinator möchte ich ausgewählte Besprechungsergebnisse weitergeben, damit ein Kollege nur die nötigen Vereinbarungen erhält.
Eine Story anhand des Interviews schreiben
Einen konkreten Fall auswählen
Suchen Sie den letzten tatsächlichen Fall. Wer hat womit gearbeitet und welches Ergebnis war nötig? „Alle brauchen Berichte“ rechtfertigt keine eigene Story.
Wortlaut und Kontext festhalten
Speichern Sie die Zeitmarke und einige Sätze davor und danach. Trennen Sie Aussage und Schlussfolgerung. Machen Sie aus einer Ausnahme keine tägliche Aufgabe.
Rolle, Handlung und Nutzen formulieren
Die Rolle soll die Situation erklären. Die Handlung soll beobachtbar sein. Der Nutzen beantwortet die Frage, warum sie der Person wichtig ist.
Umfang prüfen
Eine Story sollte nicht von der Anmeldung bis zum Jahresbericht reichen. Wählen Sie ein eigenständiges Ergebnis, das sich separat besprechen und prüfen lässt.
Akzeptanzkriterien ergänzen
Formulieren Sie Bedingungen, an denen das gewünschte Verhalten zu erkennen ist. Decken Sie Hauptfall und eine wichtige Ausnahme ab. Stimmen Sie die Kriterien mit dem Team ab, bevor sie als Kundenanforderungen gelten.
Offene Fragen erneut besprechen
Sind Zugriffsrollen, Datenumfang oder Ausgabeformat unklar, notieren Sie die Frage. Füllen Sie Lücken nicht einfach mit der vertrautesten Lösung.
Von der Aussage zur Story-Karte
Nach dem Gespräch schicke ich dem Entwickler nur seine Aufgaben. Ich kopiere sie derzeit von Hand und fürchte, interne Kommentare mitzuschicken.
Das Beispiel betrifft ein fiktives Notizsystem, keine vorhandenen Funktionen von Transkribator. Gefragt ist die Weitergabe ausgewählter Inhalte ohne zusätzliche Informationen. Die Farbe einer Schaltfläche ist dafür nicht vorgegeben.
Story. Als Projektkoordinator möchte ich ausgewählte Besprechungspunkte in einem separaten Text sammeln, damit die zuständige Person nur die für sie geltenden Absprachen erhält.
Vorgeschlagene Kriterien. Bei drei ausgewählten Punkten enthält der Text genau diese drei und keine anderen. Vor der Weitergabe sieht die Koordination den ganzen Text. Ohne Auswahl erklärt das System, dass Punkte ausgewählt werden müssen.
Offene Frage. Soll der Text Zeitmarken enthalten? Das Interview sagt nichts dazu. Klären Sie es im nächsten Gespräch, bevor es als beschlossen gilt.
Die Story hat eine Quelle. Ob der Bedarf für die meisten Kunden wichtig ist, bleibt offen. Eine Aufnahme zeigt eine Erfahrung. Priorisieren Sie getrennt anhand weiterer Belege, Produktziele und Aufwand.
Story und technische Aufgaben unterscheiden
„Datenbanktabelle anlegen“ und „Handler hinzufügen“ sind technische Aufgaben. Sie können eine Story umsetzen, erklären aber keinen Nutzen. Auch eine gute Formulierung zeigt nicht, dass das Team alle Einschränkungen kennt.
Erklären Sie die Story im Testteam ohne Namen für Bedienelemente. Wenn die Handlungen davor und danach unklar sind, lesen Sie das Interview erneut. Prüfen Sie Fälle ohne Auswahl, mit fehlender Berechtigung oder bei Wiederholung. Beschränken Sie sich auf relevante Ausnahmen.
Story-Karte mit Beleg und offenen Fragen
Titel der Story: Rolle und Arbeitssituation: Als [wer] möchte ich [Handlung], damit [Nutzen]. Quelle: Interview / Datum / Zeitmarke: Originalaussage: Unsere Deutung: Akzeptanzkriterien: 1. Bei [Bedingung] kann die Person [Handlung] ausführen und erhält [Ergebnis]. 2. Wenn [wichtige Ausnahme], erfolgt [erwartetes Verhalten]. Nicht im Umfang: Noch zu klären: Wer hat die Formulierung wann bestätigt?
- Rolle und Nutzen sind konkret.
- Das Zitat ist von der Teamentscheidung getrennt.
- Die Kriterien lassen sich beobachten und prüfen.
- Offene Fragen sind als solche gekennzeichnet.
Ein genauerer Blick
Brauchen wir immer „Als… möchte ich… damit…“?
Nein. Das ist eine hilfreiche Form. Entscheidend ist, dass das Team Person, Handlung und Grund versteht.
Wie viele Akzeptanzkriterien sind nötig?
Genug für den Hauptfall und wichtige Ausnahmen. Eigenständige Ergebnisse können getrennte Storys brauchen.
Reicht ein einziges Interview?
Sie können daraus eine Hypothese mit Quelle bilden. Das belegt keinen Bedarf eines ganzen Segments und rechtfertigt nicht automatisch Entwicklung.