6 minutes reading time (1231 words)

So schreiben Sie richtig gute User Stories

So schreiben Sie richtig gute User Stories

Wenn Sie Software entwickeln, machen Sie sich regelmäßig Gedanken, wie Ihr Team mit den Wünschen, Ideen und Anforderungen des Auftraggebers umgeht. Gibt es ein Lastenheft und einen Projektplan? Arbeiten Sie sich vom Grobkonzept zum Feinkonzept? Oder arbeiten Sie schon agil? Dann kennen Sie sicherlich User Stories - eine beliebte und bewährte Variante in Scrum. Eigentlich ganz einfach: Anforderungen werden aus Nutzersicht so weit heruntergebrochen, dass sie auf eine DIN-A6-Karte passen. Trotzdem tun sich viele Teams anfangs mit User Stories schwer. Wie schreibt man also "gute" User-Stories?

Warum User Stories sinnvoll sind

Die Ausgangslage: Der Auftraggeber und die späteren Anwender der Software sprechen im Normalfall eine andere Sprache als die Entwickler, die die Software realisieren. User Stories stellen eine Verbindung her, denn sie sind so geschrieben, dass sie für beide Parteien verständlich sind. Und sie sind – wie der Name schon sagt – immer aus Nutzersicht formuliert.

"Eine User Story beschreibt eine Funktionalität, die entweder für einen User oder einen Käufer des Systems von Wert ist."

Grundprinzipien der Arbeit mit User Stories:

  • Kundennutzen ist wichtiger als Feature
  • Ergebnis ist wichtiger als Technik
  • Kommunikation ist wichtiger als Dokumentation
  • Flexibilität ist wichtiger als vollständige Planung
  • Qualität ist wichtiger als Geschwindigkeit

Die drei C: Wie eine User Story aussehen sollte

Ron Jeffries fasste schon 2001 in seinem Blogartikel "Essential XP: Card, Conversation, Confirmation" drei wesentliche Bestandteile von User Stories zusammen: Card, Conversation und Confirmation.

"Card"

Die Formel einer User Story ist schnell erklärt: Sie besteht aus einem aussagekräftigen Titel, ist kurz und prägnant gehalten (ein bis zwei Sätze lang) und passt auf eine Karteikarte. Man verwendet einfache Sprache, vermeidet Fachbegriffe, schreibt im Aktiv statt im Passiv und fokussiert auf die relevanten Informationen. Die Story wird aus der User-Perspektive gedacht und formuliert, z.B. “Ich als Kunde, Administrator, Redakteur möchte…“

Beispiel 1: Bestellübersicht

  • Als Käufer in einem Online Shop
  • möchte ich vor der bindenden Bestellung eine Übersicht über meine Bestellung bekommen,
  • um Fehler bei der Bestellung auszuschließen.

Beispiel 2: Bestätigung Datenschutzerklärung

  • Als  Anbieter eines Portals
  • möchte ich, dass jeder neue Nutzer bestätigt, die Datenschutzerklärung gelesen zu haben,
  • um seine personenbezogenen Daten rechtlich einwandfrei für eigene Marketingzwecke verwenden zu dürfen.


    Denken Sie beim Formulieren der User-Stories nicht nur in Rollen, sondern auch in Personas. Dazu werden einige fiktive Personen erschaffen, die stellvertretend für die tatsächlichen Anwender stehen, sozusagen ein konkreter „Repräsentant“, der dem Anwender Namen, Gesicht, Alter, beruflichen und persönlichen Hintergrund gibt. Vorteil: Entwickler denken sich so noch besser in die Anwenderseite hinein als bei abstrakten Rollenbezeichnungen.

Beispiel-Personas:

Klaus Meier

  • Technischer Leiter in der Firma von Andreas Müller, 42 Jahre, Dipl. Informatiker
  • mag Science Fiction
  • ist funktionsorientiert, ihm ist es wichtig, dass er IT Systeme maximal konfigurieren kann, dass es möglichst einfach ist und am besten für alles eine Tastenkombination existiert, Design ist für ihn „buntes Beiwerk“

Susi Sorglos

  • Marketing-Verantwortliche in der Firma von Andreas Müller, 31 Jahre, hat BWL mit Schwerpunkt Marketing studiert
  • liebt Reisen, Schuhe und Handtaschen
  • Bei Software schaut sie zuerst auf die Optik und möglichst einfache Bedienung
  • Zu viele Einstellungsmöglichkeiten irritieren sie - sie möchte, dass das System einfach funktioniert

"Conversation"

Was in der Praxis oft übersehen wird: Das Arbeiten mit User Stories ist weit mehr als das Formulieren vieler kleiner Aufgaben-Kärtchen. Im Zentrum der agilen Teamarbeit steht der Dialog, worum es dem Anwender geht. User Stories werden im Team verfasst und diskutiert, und idealerweise auch mindestens einmal gemeinsam mit dem Product Owner besprochen. User Stories sind also weniger technische Spezifizierung, sondern vielmehr eine Aufforderung zur Kommunikation und eine Zusammenfassung des Besprochenen.

"Confirmation"

Weiterer wichtiger Teil jeder User Story sind die Akzeptanzkriterien – diese werden auf der Rückseite notiert und legen fest, wann die Anforderung erfüllt ist (Abnahmekriterien durch den Product Owner) und dienen meist auch als Testnotizen. Üblicherweise sind es 3 bis 6 Kriterien, die erfüllt werden müssen – ergeben sich in der Diskussion deutlich mehr (>10), ist die User Story nicht gut formuliert und vermutlich noch zu groß.

Beispiel Akzeptanzkriterien für obige User-Story 2:

  • Bei der Neuanmeldung eines Nutzers wird die entsprechende Textinformation angezeigt und muss bestätigt werden.
  • Bestätigt der Anwender die Datenschutzerklärung nicht, kann er sich nicht als neuer Nutzer am System anmelden.
  • Die Inhalte der Datenschutzerklärung müssen durch einen Verantwortlichen gepflegt werden können.

INVEST in good Stories

Eine gute Eselsbrücke für qualitativ hochwertige Product-Backlog-Elemente wurde von Bill Wake entwickelt, die sogenannten „INVEST“-Kriterien. Diese haben ihre Wurzeln im XP, finden aber auch auf User Stories in Scrum Anwendung.

Independent (I)
Sie ist nicht von einer anderen User Story abhängig

Negotiable (N)
Sie dient als Gesprächsgrundlage und kann gemeinsam weiterentwickelt werden.

Valuable (V)
Sie stellt einen Vorteil für den Anwender, Kunden oder Auftraggeber dar.

Estimatable (E)
Sie ist schätzbar. 

Small (S)
Sie hat die richtige Größe.

Testable (T)
Sie kann getestet werden.

Wie groß ist die optimale User Story?

Wann ist eine User Story so groß, dass man sie aufteilen sollte? Eine allgemeingültige Regel gibt es nicht, aber viele Teams arbeiten z.B. nach der Vorgabe, dass eine User Story inklusive Tests innerhalb von 2 bis 5 Tagen umgesetzt werden kann. Nimmt die User Story mehr als die halbe Kapazität des Sprints in Anspruch, sollte sie in kleinere User Stories zerlegt werden. Warum? Sehr groß geratene User Stories – sog. „Epics“, die zu groß für einen einzelnen Sprint sind – erzeugen fast immer Probleme. Epics lassen sich schlecht schätzen, da sie zu viele unbekannte Faktoren enthalten. Das Team erinnert sich nicht an die Diskussionen und Akzeptanzkriterien und es kommt zur Häufung von Bugs. Die Aufteilung kann nach verschiedenen Kriterien erfolgen, z.B. nach Funktionalitäten oder nach Detailtiefe. Eine gute Anleitung hierzu bietet beispielsweise das Flowchart „How to split a User Story“ von Richard Lawrence.

Und was ist Story Mapping?

Um bei komplexen Projekten den Überblick zu behalten, ist „User Story Mapping“ nach Jeff Patton empfehlenswert. Die Visualisierungsmethode bildet die User Journey orientiert am Arbeitsfluss des Anwenders auf einer zweidimensionalen „Landkarte“ nach. Story Maps erzählen auf eine ganz einfache Art, was der Nutzer vor hat, wenn er das Produkt benutzt. Sie hilft, das große Bild nicht aus den Augen zu verlieren und zeigt Fortschritte an.

„Ich erzähle im Team die Geschichte des Produkts und schreibe dabei jeden größeren Schritt, den der Nutzer macht, auf ein Post-it. Diese ordne ich von links nach rechts an. Dann gehen wir zurück und sprechen über die Details. Jedes Detail kommt auf einen weiteren Zettel und die ordne ich nacheinander unter dem jeweiligen Schritt an. So entsteht ein Raster, das von links nach rechts die Geschichte erzählt – und dazu jeweils die Details von oben nach unten beisteuert.“ (Jeff Patton)

Von links nach rechts ergibt sich ein Überblick über die Funktionalitäten und in den Spalten sind die Details der jeweiligen Funktionalität gelistet. So bilden Story Maps zu jedem Zeitpunkt das gesamte zu entwickelnde Produkt ab. Vorteil: Mit Story Maps lässt sich u.a. besser diskutieren, was zur ersten Lieferung erfüllt sein muss (MVP Minimal Viable Product) oder welche Releases geplant werden.

Fazit

Sinn der Arbeit mit User Stories ist es, dass Entwickler verstehen, was der Anwender wirklich möchte und wie er mit dem Produkt arbeitet. Dabei geht es weniger um die schriftliche Fixierung auf Karten, sondern vielmehr um die gemeinsame Diskussion im Team und die intensive Beschäftigung mit dem Nutzer.

Das möchten Sie lernen?

In unserem Live-Online-Workshop erlernen Sie in nur vier Stunden das nötige Handwerkszeug für verdammt gute User Stories - gemeinsam mit Ihrem Team unter Anleitung eines erfahrenen Trainers. Zum Online-Workshop >>

 

Bildnachweis:
Titelbild: Jacopo Romel / Flickr (CC Licence)
Storymapping: Dai Fujihara / Flickr (CC Licence)

abas 2016 – The Global Conference: Wir sind dabei!
Lean Startup: Küss den Frosch!