User Stories

Wie werden Anforderungen sinnvoll dokumentiert?

Warum Anforderungsmanagement mittels User Stories? Welches Problem wird damit gelöst?

  • Typisch: Lasten- und Pflichtenhefte – die ggf. auch vertragliche Bestandteile sind. Fokus liegt auf der technischen Umsetzung oder vertraglichen Aspekten.
  • Objektorientierte Vorgehensweisen: Use Cases (Anwendungsfälle) sind stark strukturiert, mit breitem Fokus (funktionale wie nichtfunktionale Anforderungen, Nutzer, Vorbedingungen, Einschränkungen, …).
  • Problem: Anforderungen werden typischerweise von Fachpersonen in deren Fachsprache dokumentiert – nicht mit der Sicht des Endnutzers (Fachsprache vs. Umgangssprache).
  • Der konkrete Nutzen für den (End-)Anwender spielt häufig eine untergeordnete Rolle -> Technische Details und Features stehen im Mittelpunkt anstatt der Frage: Kann der Anwender das System so nutzen, wie er es für seine Arbeit benötigt?
  • So wenig wie möglich, so viel wie nötig: User Stories müssen in einem Sprint umsetzbar sein (keine „Epic User Stories“). Damit werden Anforderungsdokumente vermieden, die „immer veraltet“ sind.

Woher kommt die Methodik?

  • User Stories werden erstmals bei eXtreme Programming erwähnt (1998)

Links, weiterführende Literatur:

  • „User Stories Applied“, von Mike Cohn, Verlag Addison-Wesley, (deutsche Übersetzung: „User Stories: für die agile Software-Entwicklung mit Scrum, XP u.a.“, mit Professional Verlag)

Als Kunde möchte ich online meine Kundendaten ändern können, um nach einem Umzug trotzdem meine Rechnungen per Post zu erhalten.

User Stories

Kurzbeschreibung User Stories geben dem Anwender und anderen Stakeholdern die Möglichkeit, in ihrer Sprache auszudrücken, welche Funktionalitäten das Produkt für sie erfüllen soll.
Verwandte Themen
Lastenheft, Pflichtenheft, Anforderungsmanagement
Wann anzuwenden
Scope Management, HR Management, Stakeholder Management
Beschreibung
Eine User Story besteht aus den Anteilen „Rolle“, „Funktionalität“ und „Geschäftswertbeitrag“, also worin der Nutzen oder Mehrwert aus Sicht des Anwenders besteht. Dadurch ist sichergestellt, dass jeder Teilnehmer am Projekt, etwa Kunden, Endnutzer oder auch andere Stakeholder ihre Wünsche ausdrücken können, ohne technische Kenntnisse zu besitzen oder sich fachlich ausdrücken zu müssen. Eine User Story wird üblicherweise verfasst in der Form: „Als [Rolle] möchte ich [Funktionalität], sodass [Nutzen].“ Jede User Story definiert Acceptance Criteria („Abnahmekriterien“).

Hinweise zu User Stories

1. I-N-V-E-S-T

 

  • Independent: Die User Story sollte in sich geschlossen sein, so dass sie keine inhärente Abhängigkeit von einer anderen User Story aufweist.
  • Negotiable: User Stories können immer geändert und umgeschrieben werden, bis sie Teil einer Iteration sind.
  • Valuable: Eine User Story muss einen Mehrwert für den Endbenutzer zu liefern.
  • Estimable: Es muss immer möglich sein, die „Größe“ einer User Story abzuschätzen.
  • Sized appropriately oder Small: User Stories sollten höchstens so groß werden, dass es noch möglich ist, sie mit ausreichender Sicherheit zu planen / als Aufgabe(n) zuzuweisen / zu priorisieren.
  • Testable: Die User Story oder ihre Beschreibung muss die notwendigen Informationen beinhalten, die die Entwicklung von Prüfmethoden ermöglichen.

 

2. User Centric

 

  • User Stories sind aus Benutzersicht zu schreiben. Klingt einfach, ist aber oft schwer einzuhalten. Hilfreich ist, sich immer einen konkreten Nutzer des Produkts vorzustellen.

Horizontaler vs. Vertikaler Split

Um eine umfassende User Story in einzelne, überschaubare Teilaufgaben zu zerlegen, bieten sich zwei Möglichkeiten an:

  • Der horizontale Split orientiert sich stark an Gewerken/Phasen.
  • Der vertikale Split definiert in sich getrennte Teilaufgaben/Liefergegenstände.

Beispielaufgabe: Setze einen Online-Shop auf.

  • Ein horizontaler Split würde vielleicht trennen nach:
    • Demand/Architektur/Design/Development/Test/Produktivsetzung
  • Ein vertikaler Split würde z.B. folgende Deliverables identifizieren, die das Gesamtprodukt ausmachen:
    • Bedienungsoberfläche, Kundendatenbank, Produktkatalog, Zahlungswege, Warenkorbsystem, …

Vorteile des vertikalen Splits:

  • Man kann einzelne Bestandteile austauschen oder streichen, ohne das Gesamtprodukt (und -vorgehen) in Frage zu stellen.
  • Man kann priorisieren.
  • Man vermeidet Silodenken („Ich bin ja nur für das Design verantwortlich“).
  • Man vermeidet Bottlenecks („Testing dauert eben so lange, wie es dauert“).
  • Weiterführende Infos unter: www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake

Hilfsbild: Man stelle sich eine Schichttorte vor (Sahne, Fruchtbelag, Kuchenboden, …). Hat der Kaffeekränzchen-Gast mehr davon, wenn man die Kuchenstücke vertikal oder horizontal schneidet?