Als Produktmanager, Business Analyst oder Systemingenieur bzw. deren Berater bist Du mit folgenden Fragen konfrontiert:

  • Welche Eigenschaften und Fähigkeiten sollte unser Produkt aus Kundensicht enthalten?
  • Was hilft uns im Entwicklungsprozess von neuen Wertangeboten?
  • Womit können die Anforderungen eines Nutzers an ein System standardisiert formuliert werden?

Unterstützung findest Du in der User Story und der nutzerzentrierten Formulierung von Anforderungen.


Überblick

Ergebnis: Anforderung eines Nutzers ermittelt, dokumentiert und abgestimmt

Teilnehmer: mind. 1 Person (Angebotsverantwortliche und Kunde) 

Dauer: ab 5 Minuten (je Anforderungskomplexität und Stakeholder)

Utensilien: Karteikarten & Stifte oder Notebook & Ticket-Software

Zweck

Mit einer User Story erfasst, dokumentierst und kommunizierst Du eine Anforderung eines Nutzers an ein Produkt, ein Service oder eine beliebige Art von System. Ein Nutzer ist dabei ein Stakeholder wie beispielweise der Käufer, Verbraucher, Anwender, Verantwortliche, Lieferant oder Betreiber.

User Stories sind aus Nutzerperspektive formuliert und beschreiben eine Eigenschaft oder Fähigkeit. Als ein prägnanter Satz in natürlicher Sprache verfasst, passen sie auf eine Karteikarte bzw. Haftnotiz.

Alternative Bezeichnungen für die User Story sind die selten verwendete Nutzergeschichte


Aufbau

Struktur

Jede User Story enthält drei Bestandteile, notiert in Umgangssprache auf der Vorderseite einer Karte (eng. Story Card).

Im englischen wird diese Struktur gern mit 3R für Role, Requirement und Reason abgekürzt bzw. mit Mike Cohn Format - dem Wegbereiter dieses Aufbaus - bezeichnet. Weniger geht es bei dem Einzeiler um eine genau Spezifikation, als um eine einfach verständliche Merkhilfe für eine offene Anforderung.

User Story
Struktur und Elemente der User Story

Eigenschaften

Eine gute User Story erfüllt fünf INVEST Kriterien, oft auch als INVEST Formel bzw. INVEST Prinzip bezeichnet.

  • Independent (dt. unabhängig) - die User Story ist unabhängig von anderen User Stories, steht also für sich als Einzelanforderung
  • Negotiable (dt. verhandelbar) - die User Story ist nicht in Stein gemeißelt, sondern eine Einladung zu Diskussionen und Anpassungen
  • Valuable (dt. wertvoll) - die User Story stellt bei Erfüllung für den Nutzer einen Wert dar
  • Estimable (dt. schätzbar) - die User Story lässt sich in ihrem Umsetzungsaufwand abschätzen
  • Testable (dt. testbar) - die User Story lässt sich in ihrem Erfüllungsgrad prüfen

Akzeptanzkriterien

Deine User Story kann - muss aber nicht - Akzeptanzkriterien besitzen. Diese definieren relevante Fertigstellungsparameter und Erfüllungsbedingungen für die Anforderung, erneut aus Nutzersicht.

Mit Akzeptanzkriterien präzisiert Du den Fertigstellungsgrad eine User Story und machst sie testbar. Nutze die Struktur...

"Eine Rolle muss sehen/fähig sein..." 

  • Akzeptanzkriterium 1
  • Akzeptanzkriterium 2
  • Akzeptanzkriterium 3

und ergänze mit

"Ausnahmefälle"

  • Ausnahmefall 1
  • Ausnahmefall 2
  • Ausnahmefall 3

(un-)erwartete Sondersituationen und Extremszenarien. Halte Akzeptanzkriterien auf der Rückseite der User Story Karte fest.


Anwendung

Eine User Story durchlebt drei Phasen: Erfassung, Abstimmung und Prüfung. Im Englischen wird dieser Lebenszyklus oft mit 3C für Card, Conversation und Confirmation bezeichnet.

  • 1

    User Story erfassen (Card)

    Erfasse jede Anforderung an ein Angebot bzw. System als eigene User Story textuell auf einer individuellen (virtuellen) Karte. Notze die 3R Struktur mit Rolle, Requirements und Reason. Prüfe die fünf INVEST Kriterien ab.

  • 2

    User Story verfeinern (Conversation)

    Jede User Story ist eine Einladung zum Dialog. Verfeinere die Story durch Akzeptanzkriterien in Arbeitstreffen, beispielsweise zusammen mit den Nutzern, dem Entwicklungsteam oder anderen Stakeholdern.

  • 3

    User Story prüfen (Confirmation)

    Nutze die User Story zur Formulierung der Nutzertestfälle sowie zur Prüfung des Liefergegenstandes. Das Ergebnis ist dann erbracht, sobald die Story und alle ihre Akzeptanzkriterien erfüllt sind.


Beispiele

User Story für ein Formel 1 Videospiel

Angenommen Du planst die Entwicklung eines Formel 1 Videospiels für Smartphones. Eine User Story könnte folgende Gestalt haben.

User Story

"Als Formel 1 Videospieler möchte ich eine Streckenkarte sehen, so dass sich ich weiß wo ich mich auf der Rennstrecke befinde."

User Story
Beispiel einer User Story 'Formel 1 Streckenkarte'

Akzeptanzkriterien

Die Akzeptanzkriterien für diese User Story könnte folgendermaßen aussehen:

"Als Formel 1 Videospieler möchte ich eine Streckenkarte sehen, die...:

  • in Form und Maßstab der realen Strecke gleicht
  • durch weiße Linien visualisiert wird, die maximal 15 Prozent des Bildschirms bedecken
  • das Auto des Spielers als blauen Punkt auf der Strecke darstellt
  • die Position des Autos auf der Karte gemäß der Position des Spielers abbildet"

Ausnahmefälle

  • "Falls das Auto explodiert, soll der Punkt auf der Streckenkarte für 1 Sekunde rot leuchten und anschließend verschwinden."

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

IBRAGOD: Top 7 Best F1 Mobile Games For Android/IOS 2020-2021 (8 min) - Impressionen von Formel 1 Videospielen auf dem Smartphone


Vor- & Nachteile

Pro

  • Eine User Story diszipliniert den Nutzer eines Angebots an den Anfang einer (Weiter-)Entwicklung zu stellen. Nicht technische Features, sondern Anwenderwünsche initiieren ein Vorhaben.
  • Inzwischen ist das Verfassen von User Stories in Entwicklungsprojekten etabliert. Viele Personen kennen das Anforderungsformat.
  • Eine User Story reduziert den Dokumentationsaufwand. Statt langer Redaktionsphasen von Pflichtenheften oder Spezifikationen, hält das Konzept zum Nutzerdialog an.

Contra

  • Die User Story bleibt eine textuelle Art der Anforderungsdokumentation. Konzepte wie der System Footprint, die Ereignisgesteuerte Prozesskette, das Kontextdiagramm oder das Use Case Diagramm visualisieren eingängig und übersichtlich eine Vielzahl von Anforderungen.
  • Auch ist die User Story weit weniger exakt und eindeutig wie Modelle und Diagrammen. Die Anforderungsspezifikationsform hat nicht den Anspruch einen Sachverhalt detailliert zu beschreiben oder gar Grundlage eines Vertrags zu sein.
  • User Stories fokussieren auf Funktionen. Qualitätsanforderungen wie Wartbarkeit, Verfügbarkeit oder Skalierbarkeit werden kaum bis gar nicht berücksichtigt.

Praxistipps

  • Tipp 1 - Viele Stories zu Epics und Sagas gruppieren

    Vereinfache die Verwaltung von mehreren User Stories, indem Du diese zu sogenannten Epics (dt. Heldengeschichten) zusammenfasst. Die Realisierung eines Epics benötigt mehrere Wochen bzw. Monate. Andersherum muss eine Epic erst in User Stories als Einzelanforderungen heruntergebrochen werden, bevor an diese umgesetzt werden können. Mehrere Epics kannst Du in einer Saga (dt. Sage, manchmal auch Initiative genannt) zusätzlich aggregieren.

  • Tipp 2 - User Story auf mehre Stories aufteilen

    Trenne eine User Story in mindestens zwei User Stories auf, falls…

    • diese nicht in einem Entwicklungsdurchgang umgesetzt werden kann bzw.
    • die Story sich nicht akkurate schätzen lässt.

    Das Story Splitting ist in der Praxis üblich, speziell wenn die User Story noch sehr jung ist. Nutze als Trennkriterien Rollen, Phasen, Anwendungsfälle, Zustände, Prioritäten etc. der User Story.

  • Tipp 3 - User Stories zu einer Story zusammenführen

    Im Gegenzug lassen sich mehrere User Stories zu einer zusammenfassen. Mache aus mindestens zwei Stories einer, falls…

    • die Stories inhaltlich zusammenpassen und
    • die kombinierte Story noch in einem Entwicklungsdurchgang umgesetzt werden kann.

    Die Kombination von Stories kommt in der Praxis sehr selten vor.

  • Tipp 4 - Stories mit anderen Methoden verbinden

    Das Konzept einer User Story eignet sich prima für die Einbettung in weiterführende Modelle und Methoden. Einige Anregungen entlang des Lebenszyklus von Anforderungen.

    • Überführe Kundenwünsche – die Voice of the Customer – in strukturierte User Stories. Vereinheitliche damit ihre Schreibweise und Struktur.
    • Verwalte User Stories in einem Product Backlog. Das Artefakt enthält alle bekannten Anforderungen an ein Produkt.
    • Integriere User Stories in die gleichnamigen Story Map und visualisiere damit die Reise eines Nutzers bei Einsatz eines Produktes oder Services.
    • Schätze den Realisierungsaufwand von User Stories im Planning Poker mit dem Entwicklungsteam.
    • Fixiere in der Definition of Done User Story-übergreifende Anforderungen an Angebot oder System.
    • Visualisiere mittels dem Burn Down Chart die bereits abgearbeiteten und verbleibenden User Stories.
  • Tipp 5 - Story mit hilfreichen Meta-Infos ergänzen

    In ihrer ursprünglichen Form besteht eine User Story aus einem Satz sowie optionale Akzeptanzkriterien. Gerne kannst Du zwecks Anforderungsverwaltung weitere Attribute hinzufügen. Einige Anregungen:

    • ID – eindeutiger Bezeichner der Story, beispielsweise aufsteigende Nummern
    • Status – Auskunft über den Zustand der Story wie dokumentiert, abgestimmt oder umgesetzt
    • Quelle – Ursprung der Story, beispielsweise der Name eines Stakeholders, IT-Systems oder Dokuments
    • Aufwand – Realisierungskosten in Zeit und oder Geld bzw. Story Points

Ursprung

Die Idee der User Story für das Anforderungsmanagement entstammt der Agilen Softwareentwicklung. Ende des 20. Jahrhunderts prägte der Informatiker Alistair Cockburn den Satz "A User Story is promise for a conversation.".

Mike Cohn dokumentiere 2004 in seinem Buch User Stories Applied: For Agile Software Development* das heute verbreitete 3R-Standardformat. Letztlich scheint es keinen einzelnen geistigen Kopf hinter dem Konzept zu geben wie auch Wikipedia berichtet.

Heute ist die User Story ein fester Bestandteil von agilen (IT-)Entwicklungsprojekten. In Ansätzen wie Scrum verwaltet der Product Owner User Stories im Product Backlog.


Bonusmaterial

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Broadcom Infrastructure Software: How to Write Good User Stories (4 min) - 3 Tipps für eine Story anhand von Beispielen erklärt

Zuletzt aktualisiert am 18. September 2021 durch Dr. Christopher Schulz

PDFDrucken

Du möchtest Consulting Methodenkompetenz als Buch?

  • 24 erprobte Consulting Tools auf > 200 Seiten
  • Mein Erfahrungswissen als eBook und Print
  • Kompakt erklärt und einfach umsetzbar
  • An einer Stelle direkt zum Nachschlagen
  • Bereits über 4.000 zufriedene Leser



Gib ein Kommentar

Your email address will not be published.