Glossar
Was ist eine User Story? Aufbau und Beispiele
Eine User Story beschreibt einen Nutzen aus Anwendersicht statt einer Aufgabe. Aufbau, Beispiele, INVEST und die Abgrenzung zu Task und Epic.
Eine User Story beschreibt eine Anforderung aus Sicht derjenigen, die den Nutzen haben — nicht als Arbeitsschritt, sondern als Ergebnis. Sie ist bewusst kurz: eine Erinnerung an ein Gespräch, keine Spezifikation.
Die Form
Als <Rolle> möchte ich <Ziel>, um <Nutzen>. Der dritte Teil ist der wichtigste und wird am häufigsten weggelassen — ohne ihn steht da nur eine Funktion, und niemand kann prüfen, ob eine andere Lösung denselben Zweck besser erfüllt.
Zwei Beispiele
Als Projektleiterin möchte ich sehen, wer diese Woche überbucht ist, um Arbeit umzuverteilen, bevor jemand ausfällt.
Als Entwickler möchte ich, dass mein Commit die Karte selbst verlinkt, um nach dem Feierabend nichts nachtragen zu müssen.
INVEST
Eine brauchbare Story ist Independent (unabhängig genug), Negotiable (verhandelbar, keine fertige Lösung), Valuable (mit erkennbarem Nutzen), Estimable (schätzbar), Small (klein genug für eine Iteration) und Testable (überprüfbar). Woran man Letzteres misst, stehen in den Akzeptanzkriterien.
Story, Task, Epic
Ein Task ist ein Arbeitsschritt („Zertifikat hinterlegen“), eine Story ein Nutzen („als Kunde möchte ich mit Apple Pay zahlen“), ein Epic die Klammer darüber („Bezahlung im Checkout“). Geschätzt wird die Story, meist in Story Points; gelagert wird sie im Backlog.
In Zuuna
Eine Story ist eine Karte mit Typ, Epic, Story Points und einer Checkliste für die Akzeptanzkriterien — dieselbe Karte, die später im Sprint und im Burndown auftaucht.
Häufige Fragen
Muss ich die „Als … möchte ich … um …“-Form benutzen?
Nein. Die Form ist eine Hilfe, kein Gesetz. Sie erzwingt nur, dass Rolle und Nutzen mitgenannt werden — wenn dein Team das ohne Schablone hinbekommt, ist die Schablone überflüssig.
Wie klein sollte eine User Story sein?
Klein genug, dass sie in einer Iteration fertig wird. Was regelmäßig nicht fertig wird, ist zu groß — dann zerlegen, nicht die Iteration verlängern.
Ist jede Karte eine User Story?
Nein. Fehlerbehebungen, technische Aufgaben und Wartung haben keinen Anwendernutzen im Story-Sinn. Sie in die Schablone zu pressen erzeugt Sätze wie „als Entwickler möchte ich die Datenbank migrieren“ — das hilft niemandem.