So einfach schreibst Du gute User Stories

Das Ziel von User Stories ist es, die Anforderungen an ein Produkt oder Service in einer einfachen und gemeinsamen Sprache zu beschreiben, sodass sich daraus Diskussionen bilden können.

Die Stories werden immer aus Perspektive des Nutzers (der Rolle) geschrieben. Sie konzentrieren sich auf den Erwartungen (Was?) und der Motivation (Warum?).
Der Fokus liegt also immer auf den Erwartungen und dem Nutzen, nie auf dem Wie etwas umgesetzt wird (keine fachlich, technischen Diskussionen).

Epic → User Stories → Aufgaben

Zu Beginn eines Projektes ist es ganz normal, dass ein Großteil der „User Stories“ viel zu groß und umfangreich sind. Diese großen Stories werden als Epics bezeichnet. Im Laufe der Diskussionen mit dem Team, werden dann die Epics in mehrere, kleine User Stories zerlegt.

Es ist dabei wichtig darauf zu achten, dass auch die einzelnen Stories eine klare Erwartung und Nutzen aufweisen.

Aufbau einer User Story

Wie eine Story geschrieben wird, erfolgt meist einem festen Aufbau:

Um / Damit / Weil [Wert], möchte ich als [Rolle] [Funktion].

[Wert] – Warum?

Das Warum macht einen Satz erst zu einer richtigen User Story, denn die Beantwortung dieser Frage gibt erst den richtigen Kontext. Wenn diese Frage nicht (sinnvoll) beantwortet werden kann, ist dies ein Hinweis darauf, dass die (wirklichen) Anforderungen der Kunden noch nicht vollständig verstanden wurden.

→ Das Warum ist manchmal wichtiger als das Was bei einer Story, da hier meist entscheidende Informationen über Hintergründe, Motivationen und dem Kontext beantwortet werden.

[Rolle] – Wer?

Hier wird die Frage beantwortet, wer der Nutzer (Rolle, Persona) einer Funktion (Was?) ist. Zumeist sollte dies der Kunde/Nutzer sein, aber nicht ausschließlich. Valide Rolle sind z.B. auch …

  • … als Marketingverantwortlicher …
  • … als Buchhalter …
  • … als Administrator …

→ Es sollte immer darauf geachtet werden, dass eine Story aus der echten Nutzer-Rolle geschrieben wird und nicht auf einer „Pseudo“-Rolle. Beispielsweise wünscht sich die Rolle Verkäufer oder Marketing gerne alles Mögliche für den Verkauf auf einer Website, aber hat auch der Kunde/Nutzer etwas davon?

[Funktion] – Was?

  • Was sind die Erwartungen, Ziele und Wünsche der Rolle?
  • Was braucht die Rolle und erwartet sie?

Beispiele

Um bessere User Stories zu schreiben, möchte ich als Projektmanager wissen, wie diese am besten aufgebaut werden können.

Damit ich die personenbezogenen Daten meiner Kunden legal im Marketing verwenden kann, möchte ich als Anbieter, dass alle neuen Nutzer bei der Registrierung, die Datenschutzerklärung akzeptiert haben.

Ist meine User Story gut geschrieben?

Die INVEST-Kriterien sind eine gute Möglichkeit um zu überprüfen, wie hochwertig eine User Story ist:

Independent (unabhängig)

  • Jede User Story sollte möglichst unabhängig von anderen Stories sein.
  • So sollte es möglichst keine Stories geben, welche die Entwicklung der aktuellen Story blockieren. Ansonsten kann es passieren, dass erst andere – unter Umständen weniger wertvolle – Stories realisiert werden müssen, bevor die Wertschaffende Story umgesetzt werden kann.

Negotiable (verhandelbar)

  • User Stories sind nicht in Stein gemeißelt.
  • Product Owner, Stakeholder, Designer, Entwickler, … arbeiten, diskutieren und präzisieren diese gemeinsam.

Valuable (nützlich)

  • Eine Story muss für den Nutzer (Rolle) immer sinnvoll sein und einen Wert haben.

Estimable (schätzbar)

  • Eine Story darf nur so groß sein, dass Entwickler den Aufwand sinnvoll schätzen können.

Small (klein)

Testable (testbar)

Die Story definiert die Akzeptanzkriterien

Nachdem eine Story vom Team gemeinsam diskutiert wurden, kann der Product Owner die Stories um Akzeptanzkriterien erweitern. Bei klassischen Story Cards werden diese meist auf der Rückseite notiert.
In den Akzeptanzkriterien werden die fachlichen Anforderungen definiert. Sie beschreiben, ab welchem Zeitpunkt eine User Story als erfüllt gilt (Definition of Done). Jede Story besteht meistens aus 3 bis 6 Kriterien. Sobald mehr als 10 Kriterien benötigt werden, um die Anforderungen einer Story vollständig festzulegen, ist das ein Indikator für eine zu große User Story.

Die Akzeptanzkriterien können sich – genauso wie die User Story – im Prozess jederzeit verändern, überarbeitet oder konkretisiert werden.
Es gibt dabei nur eine Regel: Sobald eine Story in einen Sprint gezogen und dieser begonnen wurde, dürfen weder Story noch Akzeptanzkriterien mehr verändert werden.