Die User Story – Anforderungen nutzerorientiert erfassen

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.

Ergebnis: Ermittlung, Dokumentation, und Abstimmung der Anforderung eines Nutzers

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, Aufftraggeber 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.

Synonyme für die User Story ist die selten verwendete Nutzergeschichte.

Aufbau

Struktur – „Wie ist eine User Story aufgebaut?“

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

• „Als Rolle…“ – repräsentiert den Nutzer mit der Anforderung
• „…möchte ich Anforderung…“ – die Eigenschaft, Fähigkeit oder Funktion
• „….damit Grund.“ – der Zweck, Ziel, Problemlösung oder Nutzen der Anforderung.

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.

Eigenschaften – „Was zeichnet eine gute User Story aus?“

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 – „Wie lässt sich eine User Story präzisieren?“

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 von Nutzertestfällen 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.“

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.“

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…

• bereits ein Teil der Story einen fachlichen Mehrwert erzeugt,
• die Story sich nicht akkurate schätzen lässt bzw.
• diese nicht in einem Entwicklungsdurchgang umgesetzt werden kann.

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 User Story zusammenfassen. Mache aus mindestens zwei Stories eine, 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 weiteren 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 Zusatzinfos aufwerten

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
• Datum – verschiedene Datumsangaben wie Umsetzungsstart- bzw. Endzeitpunkt
• Aufwand – Realisierungskosten in Zeit und oder Geld bzw. Story Points
• Verweise – weiterführendes textuelles oder grafisches Material zur User Story

Beachte: Jede Zusatzeigenschaft ist nützlich, führt jedoch auch zu Erfassungs- und Pflegeaufwänden.

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

User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck)) (English Edition)

17,97 EUR

Bei Amazon kaufen Preis inkl. MwSt., zzgl. Versandkosten

Letzte Aktualisierung am 19.04.2024 / Affiliate Links / Bilder von der Amazon Product Advertising API