Wenn Sie Produkte 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 bewährte Variante in Scrum, die sich aber auch für das Anforderungsmanagement in anderen agilen Frameworks eignet. 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 richtig gut User-Stories?

Das Ziel

Sinn der Arbeit mit User Stories ist es, dass Produktentwickler 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.

Frage stellen

Tipp

Auf unserer Q&A-Plattform "Teamprove Wissen" können Sie alle Ihre Fragen rund um agiles Arbeiten mit unserer Community diskutieren. Auch unsere Coaches sind aktive Mitglieder, so dass Sie auf jede Frage schnell eine qualifizierte Antwort erhalten.
Frage stellen

Warum User Stories sinnvoll sind

Die Ausgangslage: Der Auftraggeber und die späteren Nutzer des Produkts sprechen häufig eine andere Sprache als die Produktentwickler. 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.

Tipp

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: Produktentwickler 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

Das User Story Format ist sicherlich nicht die einzige Möglichkeit, um Anforderungen für das Product Backlog zu erzeugen – wir haben aber die Erfahrung gemacht, dass das User Story Format dazu zwingt, sich intensiv mit den Nutzererwartungen auseinanderzusetzen und diese „auf den Punkt“ zu bringen. Wir unterstützen Sie gerne dabei, das Arbeiten mit User Stories zu erlernen oder noch besser zu machen.

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

Beitrag teilen

Fasziniert von agilen Methoden begleitet Matthias Pauers Führungs­kräfte auf dem Weg zum „Agile Leader“ und unterstützt Organisationen beim Change Management. Seine Schwer­punkte sind Unternehmens­kultur und Führung, Coaching, Anforderungs­management und Design Thinking.

Kategorien