Was ist eine User Story?

In agilen Verfahren wie Scrum werden Anforderungen grundsätzlich anders behandelt als im klassischen Requirements Engineering (RE) und im traditionellen Projektmanagement (PM), nämlich üblicherweise mit Hilfe von Benutzergeschichten (User Stories). Was sind Benutzergeschichten und wie unterscheiden sie sich von anderen Anforderungsarten und -verfahren? In diesem Beitrag beschreibe ich erst mal, was eine Benutzergeschichte ist und werde dann in einem späteren Beitrag darauf aufbauend die Benutzergeschichte u.a. vom Anwendungsfall abgrenzen.

Sollte ich Benutzergeschichte mit einem Satz definieren, würde ich sagen: Eine Benutzergeschichte beschreibt eine Eigenschaft (i.d.R. eine Funktionalität) eines Systems, die für dessen Anwender oder Käufer einen kaufentscheidenden Wert darstellt.

Eine Benutzergeschichte ist dabei anfänglich keine Anforderung im engeren Sinne, sondern nur ein Merker für eine noch zu besprechende Anforderung. Eine Benutzergeschichte repräsentiert zunächst also nur die Forderung nach einem Anforderungsdiskurs (d.h. einem Gespräch über die Anforderung), aber nicht die Anforderung selbst. Erst im Zuge dieses Diskurses wird daraus dann auch ein Ergebnisdokument. „Benutzergeschichten ersetzen das Gespräch […] nicht, sondern dokumentieren dessen Ergebnis.“ (Roman Pichler in „Scrum – Agiles Projektmanagement erfolgreich einsetzen„)

Für die Beschreibung einer Benutzergeschichte ist folgende syntaktische Phrase (kanonische Beschreibungsform einer Benutzergeschichte) üblich: „Als <Benutzerrolle> kann ich <Aktivität>, um <Nutzen> zu erreichen.“ Beispiel: „Als Bibliothekar kann ich einen neuen Buchtitel erfassen, um das Buch verfügbar zu machen.“

Der Anforderungsdiskurs endet mit der Vereinbarung schriftlich festgehaltener Akzeptanzkriterien, wodurch eine Benutzergeschichte eine Anforderung im engeren Sinne wird und bereit zur Umsetzung ist. Eine Benutzergeschichte, die bereit zur Umsetzung ist, soll die INVEST-Kriterien erfüllen. Benutzergeschichten beschreiben nur solche Eigenschaften und Erwartungen, die noch nicht durch die Definition von Fertig abgedeckt sind. Die Definition von Fertig gilt implizit für jede Benutzergeschichte.

Eine Benutzergeschichte (BG) ist also eine RE-Technik. Benutzergeschichten sind Verfeinerungen von (Scrum-)Epen oder sind in (Scrum-)Themen aggregiert.

Typische Inhalte und Struktur einer Benutzergeschichte sind (vgl. http://www.projekt-log.de/projektmanagement/die-struktur-des-heiligen-grals/ sowie http://www.oose.de/detail/produkt_backlog_agil.html):

  • ID: Eindeutige Identifizierung, z.B. eine laufende Nummer
  • Name: Kurzbezeichnung
  • Priorität
  • Größe oder Aufwand: die vom Team geschätzte Größe
  • Hinweise auf besondere Chancen und Risiken
  • Ggf. Epos: Aus welchem Epos wurde die BG abgeleitet?
  • Fachliches Thema: zu welchem übergeordneten Thema diese BG gehört, bspw. um alle Einträge zu einem Thema gemeinsam zu repriorisieren
  • Syntaktische Phrase (also die eigentliche Benutzergeschichte: „Als … möchte ich … um zu …“
  • Akzeptanzkriterien (um festzustellen, ob die Anforderung fertig umgesetzt wurde, d.h. was am Iterationsende zu demonstrieren ist)
  • Begutachtungs-/demonstrationshinweise (grobe Beschreibung, *wie* diese Benutzergeschichte zum Iterationsende demonstriert werden soll)
  • Urheber, Anfordernder Stakeholder: Von wem stammt diese BG? Diese Person kann ggf. weiterführende Informationen liefern, falls der Product Owner (PO) dies nicht kann.
  • BG-spezifischer Kommunikationsplan: Wer sollte mit wem welche Aspekte besprechen? Bspw. Kunde, Management, Team, andere Teams über Chancen, Geschäftswert, Risiken, Aufwand etc.
  • Evtl. Lösungsideen/-empfehlungen etc.

Es sind noch viele weitere Attribute denkbar. Hier gilt jedoch: Weniger ist mehr. Jeder Product Owner muss also überlegen, welche Attribute er wirklich braucht.

Ist eine Benutzergeschichte eine Anforderung?
Anforderungen im engeren Sinne sind nur die zu einer Benutzergeschichte vereinbarten Akzeptanzkriterien. Eine Benutzergeschichte ohne Akzeptanzkriterien stellt keine vertragliche Verpflichtung dar.

Wie groß sollte eine Benutzergeschichte sein?
Benutzergeschichten haben anfänglich keine bestimmte inhaltliche Größe (außer dass sehr große Benutzergeschichten Epen genannt werden). Im Product Backlog (PBL) höher priorisierte Benutzergeschichten sind i.d.R. feingranular. Die niedrig priorisierten Benutzergeschichten sind i.d.R. grobgranular und werden ggf. Epen genannt. Die Größe von Benutzergeschichten, die Bereit zur Umsetzung sind, muss klein genug sein, um von einem Entwicklungsteam in einer Iteration umgesetzt zu werden (also kleiner als die entsprechende Entwicklungskapazität). Bei der Verwendung von Story Points (SP) gelten Größen von 1-13 SP als angemessen für Benutzergeschichten die bereit zur Implementierung sind. Größere Benutzergeschichten gelten als Epen und sollten weiter verfeinert werden.

Typischer Fehler: zu umfangreiche Beschreibungen
Eine BG ist keine Anforderung im engeren Sinne, weswegen keine vollständige und konsistente Beschreibung angestrebt wird. Eine BG sollte nur so viel Text enthalten, dass die Beteiligten die Anforderung überhaupt identifizieren und von anderen unterscheiden können. Alles weitere wird stattdessen mündlich geklärt und ist mit Hilfe von Akzeptanzkriterien zu beschreiben. Zu umfangreiche BG sind also ein Hinweis darauf, dass der Anforderungsdiskurs vernachlässigt wurde oder Akzeptanzkriterien fehlen.

Schlagwörter: , ,

No Comments.

Leave a Reply

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert. *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>