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:

Independent (unabhängig):	Es muss möglich sein die User Story unabhängig von anderen Stories zu implementieren.
Negotiable (verhandelbar):	Es muss möglich sein die User Story bis zum Beginn der Implementierung verändern zu können.
Valuable (wertvoll):	Die User Story muss einen Nutzen haben.
Estimatable (schätzbar):	Es muss möglich sein den Implementierungsumfang der User Story zu bewerten.
Small (klein):	User Stories sollten nicht so umfangreich sein, dass es nicht mehr möglich ist sie einzuplanen oder sie zu priorisieren.
Testable (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:

Slice- (Schnitt-) Methode	Beschreibung
Schnitt entlang von funktionalen Abhängigkeiten	Viele 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äten	Manchmal 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 / Rollen	In 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 Prozessschritten	Viele 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 Wissensstands	Oftmals 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.