zettelweltLetzte Woche musste ich mal wieder User Stories schreiben. Irgendwie hatte ich im ganzen letzten Jahr nie eine Anforderung User Stories von der Grundlage ab zu schreiben – meistens waren diese schon da und ich habe diese nur gelesen. Höchste Zeit das ich mich mal wieder auf den Stand bringe wie man eine gute User Story schreibt – und damit hier alles rund um User Stories zusammenfasse, damit ich beim nächsten mal nicht mehr suchen muss – und ihr ggf. auch nicht.

Zunächst vielleicht für alle die sich nicht mit der agilen Projektarbeit auskennen: User Stories versuchen der Babelfisch zwischen Fachabteilungen und Technikern. Eine Fachabteilung kann das Framework der User Story nutzen um die Anforderungen die Sie haben aufzuschreiben und die Techniker verstehen diese – und andersrum. User Stories sind damit das allheilmittel für eine Fachübergreifende Kommunikation. Äh…hust. Also könnten Sie sein. Irgendwie sind User Stories (leider) mehr so etwas wie Esperanto – wenn wir alle diese Sprache beherrschen würden, wäre das mit den Übersetungen in fremde Sprachen nicht mehr nötig. Leider – aber vermutlich aus gutem Grund – lernt kein Mensch Esperanto.

Das schreiben und finden der richtigen User Story geht es ähnlich. Der erste Ansatz ist ganz einfach – eine User Story folgt folgendem Muster:

Als <Wer> möchte ich <Was> damit <Warum>

„Als Benutzer möchte ich beim eingeben im Suchfeld automatisch Suchvorschläge sehen, damit ich hier schneller zu dem richtigen Suchbegriff anklicken kann“.  Als Fachabteilung kann man diverse solcher Sätze schreiben.

Die Empfehlung ist die User Storys zusammen zu schreiben – also Entwickler und Fachabteilung als Einheit.

Wenn das ganze erstmal einen gewissen Flow hat sind hier aber User Storys von der Fachabteilung direkt und nicht von den Entwicklern gewünscht. Entwickler erstellen in der Regel sowieso noch weitere Stories – „Technical Storys“.

Um eine „gute“ User Story zu schreiben gibt es folgende Regeln / Ideen / Vorgaben:

  1. Immer aus der Sicht des Benutzers schreiben – lasst euch nicht verführen von technischen oder abstrakten Sätzen
  2. Die 3’Cs – Card, Conversation, Confirmation. Soll heissen: schreibt eure User Storys auf Karten, Sprecht drüber und stimmt dann zusammen ab wie die Story „gut“ werden kann – der letzte Fall lässt sich im Normalfall mit Akzeptanztest erreichen. Niemand braucht nutzlose Planungsstories.
  3. Die INVEST Regel –
    • Independent – also unabhängig. Eine Story sollte alleine in einem Sprint lösbar sein.
    • Negotiable – Schaffbar. Eine User Story von der man vorher weiss, das sie nicht zu lösen ist kann man gleich lassen.
    • Valueable – die Story soll einen Nutzen haben
    • Estimatable – Schätzbar. Zumindest aber „absehbar“ welche Größe die Story hat – nicht unbedingt in Stunden, aber im Verhältnis zu anderen Aufgaben.
    • Small – Lieber zu klein als zu groß
    • Testable – Man sollte die User Story testen können
  4. User Stories sind keine Pflicht – wenn sich eine Anforderung besser anders beschreiben lässt – z.B. durch Mindmaps, Prozesszeichnungen, Designs – dann quält euch nicht indem ihr eine User Story schreiben wollt. Die Story alleine ersetzt auch nicht die Konzeption, die Use Cases, eine Architekturskizze oder ähnliche Anforderungsdefinitionen.

Der Entwicklung reicht die normale User Story – als der eine Satz in der Regel aber nicht – das Feuer liegt in den Akzeptanzkriterien. Diese ermöglichen einen Detaillevel der für Entwickler die nötige Tiefe darstellen. Akzeptanzkriterien lassen sich am sinnvollsten in folgende Überschriften unterteilen:

  1. Vorbedingung
  2. Testfälle
  3. Erwartetes Ergebnis
  4. Testdaten

Um einen Akzeptanztest zu schreiben nimmt man sich am besten das Hauptverb und das Substantiv um die User Story und erweitert diese durch Was, Wann, Wie Fragen. In der Summe sollten 3-6 Akzeptanzkriterien je Story reichen.

Links:

Bildquelle: