User Story Management

Anforderungen werden in der agilen Softwareentwicklung oft anhand von „User Stories“ beschrieben. Das sind kurze Geschichten, die die Nutzung aus Sicht von unterschiedlichen Anwendern darstellen.

Agile Softwareentwicklung in aller Kürze

Eine Herausforderung für Softwareentwickler ist es, die Anforderungen von Nutzern in einer verständlichen und nachvollziehbaren Art und Weise aufzuschreiben. Im klassischen (Wasserfall-) Projektmanagement werden vor dem Beginn der Implementierung alle Spezifikationen in umfangreichen Dokumenten zusammengeschrieben. Oft werden Anforderungen zunächst grob in einem Lastenheft beschrieben, um sie dann anschließend in einem Pflichtenheft zu konkretisieren. Eine andere Variante ist es, die fachlichen Anforderungen in einem Fachkonzept und die technischen Umsetzungshinweise in einem Systemkonzept zu beschreiben. Nachdem die Beschreibung des Projektumfangs abgeschlossen ist, wird mit der Implementierung begonnen. Schwachpunkt dieses Vorgehens ist, dass zu dem Zeitpunkt, an dem die Konzepte geschrieben werden, nämlich ganz zu Beginn des Projekts, am wenigsten über die Anforderungen und Voraussetzungen bekannt ist.

Diesem Umstand versucht die agile Softwareentwicklung gerecht zu werden, indem zu Projektbeginn nur eine sehr grobe Beschreibung der Anforderungen aufgestellt wird. In der am weitesten verbreiteten agilen Methodik, Scrum (vgl. z.B. State of Agile Report 2016) , werden im sogenannten „Product Backlog“ alle Anforderungen als „Features“ aufgenommen und priorisiert. Anschließend werden alle Features anhand von „User Stories“ konkretisiert. Begonnen wird mit dem am höchsten priorisierten Feature. User Stories beschreiben rein fachlich Funktionen der Software. Mit der Zeit, spätestens vor Beginn der Implementierung, werden die User Stories durch das Entwicklungsteam analysiert und der Umfang bewertet. Der Vorteil dieses Vorgehens ist, dass die konkrete Umsetzung erst dann konzeptioniert wird, wenn die Umsetzung kurz bevor steht. Dadurch können alle bereits gewonnenen Erkenntnisse und inhaltlichen Änderungen berücksichtigt werden.

In der agilen Softwareentwicklung ist es so, als ob man mit Anforderungsdokumenten beginnt, in denen bisher nur die Überschriften und groben Rahmenbedingungen beschrieben sind. Der restliche Inhalt und alle Details, werden nach Beginn der Entwicklung, fortlaufend, eingetragen.

User Stories

Der Grundsätzliche Aufbau von User Stories ist ganz einfach, sie bestehen aus einer kurzen fachlichen Beschreibung und Akzeptanzkriterien. Die fachliche Beschreibung umfasst i.d.R. einen Satz in dieser Form:

Als [Rolle] möchte ich [Beschreibung der Funktion] um [Nutzen].

In einem Projekt zur Entwicklung einer Anwendung zur Arbeitszeiterfassung könnten z.B. diese Anforderungen definiert werden.

Als Abteilungsleiter möchte ich eine Übersicht aller Mitarbeiter in meiner
Abteilung aufrufen können, um Auswertungen durchführen zu können.

 

Als Mitarbeiter möchte ich mein Überstundenkonto einsehen können
um Einblick in den aktuellen Stand meines Arbeitszeitkontos zu haben.

 

Als Administrator möchte ich, dass neue Mitarbeiter automatisch aus dem Benutzerverzeichnis
übernommen werden, damit das nicht manuell gemacht werden muss.

Bei der Formulierung von User Stories ist es wichtig darauf zu achten, dass sie die INVEST-Kriterien erfüllen:

I ndependent (unabhängig):Es muss möglich sein die User Story unabhängig von anderen Stories zu implementieren.
N egotiable (verhandelbar):Es muss möglich sein die User Story bis zum Beginn der Implementierung verändern zu können.
V aluable (wertvoll):Die User Story muss einen Nutzen haben.
E stimatable (schätzbar):Es muss möglich sein den Implementierungsumfang der User Story zu bewerten.
S mall (klein):User Stories sollten nicht so umfangreich sein, dass es nicht mehr möglich ist sie einzuplanen oder sie zu priorisieren.
T estable (testbar):Die User Story ist so beschrieben, dass es möglich ist Tests für sie zu formulieren.

Die fachliche Beschreibung reicht bei weitem nicht aus, um die INVEST-Kriterien zu erfüllen, daher werden User Stories um sogenannte Akzeptanzkriterien ergänzt. Sowohl fachliche als auch technische Anforderungen können dabei als Akzeptanzkriterien angegeben werden. Für die oben genannten User Stories könnten u.a. diese Akzeptanzkriterien genannt werden:

User StoryAkzeptanzkriterien
Als Abteilungsleiter möchte ich eine Übersicht aller Mitarbeiter in meiner Abteilung aufrufen können, um Auswertungen durchführen zu können.
  • Liste aller Mitarbeiter der Abteilung des Abteilungsleiters
  • Abteilungsleiter können nur ihnen zugewiesene Mitarbeiter einsehen
  • Auswertung von Gesamtüberstunden in der Abteilung (absolut und zeitliche Entwicklung)
  • Übersicht Regelarbeitszeit je Mitarbeiter
Als Mitarbeiter möchte ich mein Überstundenkonto einsehen können, um Einblick in den aktuellen Stand meines Arbeitszeitkontos zu haben.
  • Absolute Zahl der Überstunden
  • Zeitliche Entwicklung als 6-Monats-Graph
Als Administrator möchte ich, dass neue Mitarbeiter automatisch aus dem Benutzerverzeichnis übernommen werden, damit es nicht manuell gemacht werden muss.
  • Neue Mitarbeiter sollen sich innerhalb von 1 Std. nach Anlage im Benutzerverzeichnis an der Zeiterfassung anmelden können
  • Benutzerverzeichnis ist ein LDAP
  • Diese Attribute werden aus dem LDAP übernommen:
  • Name, Vorname, Abteilung, E-Mail Adresse

Durch die Akzeptanzkriterien wird der durch das Entwicklungsteam umzusetzende Inhalt viel deutlicher und konkreter. Je näher eine User Story ihrer Implementierung kommt, desto konkreter muss sie formuliert werden, bzw. desto vollständiger müssen die Akzeptanzkriterien werden. Sobald eine Story in einen Sprint eingeplant wird, darf sie nicht mehr ohne Rücksprache mit dem Team verändert werden, da sonst der Scope (Umfang) verändert würde.

Im Alltag

In Scrum ist der Product Owner für die Priorisierung und die Detailierung der User Stories im Product Backlog verantwortlich. In sogenannten Backlog Refinement Meetings hat er die Möglichkeit Stories aus dem Product Backlog mit dem Entwicklungsteam zu diskutieren und deren Aufwand schätzen zu lassen.

Durch die Diskussion mit dem Team werden i.d.R. neue Akzeptanzkriterien gefunden. Wenn das Team der Meinung ist, dass eine Story noch zu groß für die Aufwandsschätzung ist, oder sie in der aktuellen Form nicht eindeutig umsetzbar ist, muss der Product Owner diese Story auf mehrere neue Stories aufteilen. Hierfür gibt es eine Vielzahl von Möglichkeiten.

Slice- (Schnitt-) MethodeBeschreibung
Schnitt entlang von funktionalen AbhängigkeitenViele Funktionen müssen in unterschiedlichen Bereichen implementiert werden (z.B. Front- und Backend). So kann erst das Frontend in einer Story entwickelt werden und später das Backend in einer anderen Story.
Trennung von schnell und aufwändig zu implementierenden FunktionalitätenManchmal ist es vorteilhaft, wenn man einen Teil einer Story schnell präsentieren kann (z.B. um Feedback zu bekommen). Dann ist es sinnvoll die ursprüngliche Story auf mehrere Stories aufzuteilen und zwar anhand der zu erwartenden Implementierungsdauer.
Trennung entlang von Nutzern / RollenIn der Diskussion von User Stories können Akzeptanzkriterien von unterschiedlichen Rollen, oder Nutzergruppen aufkommen. Sobald dies auffällt, sollte die User Story zerteilt werden, so dass jede User Story eindeutig einer Nutzergruppe/Rolle zuzuordnen ist.
Teilung nach ProzessschrittenViele Funktionen bestehen aus mehreren Prozessschritten (z.B. Registrierung, Bestätigungsmail, 1. Anmeldung, Änderung Initialpasswort). Jeder Prozessschritt kann eine User Story bilden.
Schnitt auf Basis des aktuellen WissensstandsOftmals gibt es Aspekte einer User Story, für die es bereits konkretere Vorstellungen gibt als für andere Teile der Story. Dann kann es sinnvoll sein die bereits sehr konkreten Aspekte in einer Story zusammen zu fassen. Diese kann dann schon implementiert werden und trägt ggf. zur Konkretisierung der anderen Aspekte bei.

Neben den oben genannten Methoden zur Zerteilung von User Stories gibt es noch viele andere. Es gibt keine Art der Teilung, die verboten ist. Je nach User Story gibt es aber immer eine Methode die sinnvoller ist als andere.

Unsere Beispielstories könnten beispielsweise wie folgt zerteilt werden.


Als Abteilungsleiter möchte ich eine Übersicht aller Mitarbeiter in meiner
Abteilung aufrufen können, um Auswertungen durchführen zu können.

Als Abteilungsleiter möchte ich eine Übersicht aller Mitarbeiter in meiner Abteilung aufrufen können, um einen Überblick zu bekommen.Als Abteilungsleiter möchte ich Auswertungen über die gebuchten Zeiten der Mitarbeiter meiner Abteilung machen können, um eine Übersicht der geleisteten Arbeitsstunden, z.B. je Projekt, zu bekommen.

Methode: Schnitt auf Basis des Wissensstands. Es ist noch nicht bekannt, welche Art von Auswertungen benötigt wird. Die Übersicht der Mitarbeiter einer Abteilung kann aber schon implementiert werden.


 


Als Mitarbeiter möchte ich mein Überstundenkonto einsehen können,
um Einblick in den aktuellen Stand meines Arbeitszeitkontos zu haben.

Als Mitarbeiter möchte ich, dass meine Überstunden täglich aktuell berechnet werden, damit immer der aktuelle Stand meiner Überstunden vorhanden ist.Als Mitarbeiter möchte ich den aktuellen Stand meiner Überstunden in der Zeiterfassung einsehen können, damit ich mich immer selber über den aktuellen Stand informieren kann.

Methode: Teilung nach Prozessschritten. Die erste User Story umfasst die Berechnung der Überstunden, die Akzeptanzkriterien können sich also auf deren korrekte Berechnung konzentrieren. Die zweite User Story fokussiert sich auf die Abfrage des aktuellen Stands, basiert also auf dem korrekten Ergebnis.


 


Als Administrator möchte ich, dass neue Mitarbeiter automatisch aus dem Benutzerverzeichnis übernommen werden,damit es nicht manuell gemacht werden muss.

Als Administrator möchte ich, dass regelmäßig die Mitarbeiter und deren Attribute mit dem Benutzerverzeichnis synchronisiert werden, damit in der Zeiterfassung immer die aktuellen Daten angezeigt werden.Als Abteilungsleiter möchte ich, dass neue Mitarbeiter schon an ihrem ersten Tag Zeiteinträge in der Zeiterfassung anlegen können, damit sich die Mitarbeiter willkommen fühlen und die Einträge nicht nachträglich eingetragen werden müssen.

Methode: Trennung entlang von Nutzern/Rollen. Durch die Rolle des Abteilungsleiters für diese User Story wird ein neuer Aspekt eingebracht, der auch neue Akzeptanzkriterien generieren kann. Dadurch wird der Nutzen des Features verbessert.


 

Natürlich kann eine User Story in beliebig viele neue User Stories aufgeteilt werden. Bei der Teilung ist darauf zu achten, dass auch die Akzeptanzkriterien entsprechend auf die neuen Stories verteilt werden. Die Größe von User Stories sollte immer so sein, dass ein Entwicklungsteam mehrere Stories pro Iteration implementieren kann.

Das wichtigste bei User Stories ist, diese auch wirklich im Team zu diskutieren. Es bringt nichts wenn sich ein Product Owner hinsetzt und User Stories schreibt und diese dann an das Entwicklungsteam übergibt. Das wäre in etwa das gleiche Ergebnis wie ein Lastenheft das von einer einzelnen Person geschrieben wurde. Zweck der Diskussion von User Stories ist es, ein gemeinsames Verständnis im Team zu schaffen. Dabei ist es auch wichtig die Ergebnisse festzuhalten, schriftlich oder in Bildern, damit bei der Implementierung darauf zurückgegriffen werden kann.

Fazit und Ausblick

Im Verlauf eines Scrum Projektes müssen auf Basis des priorisierten Product Backlogs die User Stories immer weiter ausgearbeitet, diskutiert und detailliert werden. Eindeutige User Stories, die alle notwendigen Anforderungen umfassen, sind dabei die Grundlage für ein erfolgreiches Produkt, denn sie bilden das Fundament für die spätere Entwicklung. Neben dem Inhalt sind alle weiteren INVEST-Kriterien, wie Testbarkeit oder die überschaubare Größe, notwendig für gute User Stories. Daher ist es wichtig, dass man eine Story bei Bedarf entsprechend der Begebenheiten auf mehrere neue Stories aufteilt und dadurch den Umfang jeder einzelnen Story auf ein überschaubares Maß bringt und zum anderen auch die Möglichkeit nutzt, um aus unterschiedlichen Blickwinkeln und mit unterschiedlichem Fokus auf denselben Aspekt zu schauen.

Diesen Beitrag teilen

Daniel Huchthausen
Consultant
Wenn er nicht gerade die Wildnis erkundet, beschäftigt sich Daniel mit Themen wie Qualitätssicherung, Testen oder PM-Methoden.