User Story Management

Requirements in agile software development are often described based on “User Stories”. These are short stories which illustrate the use from the users perspective.

Agile software development in brief

Taking down user requirements in a clear and transparent manner can be a challenge for software developers. With classic (waterfall) project management, all specifications are compiled into extensive documents before beginning with the implementation phase. Requirements are often first roughly described in a user requirements specification in order to then finalise them in a functional specification. Another variation would be to describe the functional requirements in a functional concept paper and the technical implementation strategy in a system concept paper. After the description of the project scope has been completed, the implementation phase begins. A flaw in this approach is that at the time of writing the concept papers, namely right at the beginning of the project, little is known about the requirements and preconditions.

Agile software development tries to fix this by only compiling a very rough description of requirements at the beginning of the project. In the most widespread agile methodology, Scrum (cf. e.g. State of Agile Report 2016), all requirements are incorporated in the so-called “Product Backlog” as “Features” and prioritised. Subsequently, all features are concretised in “User Stories”. We start with the highest priority feature. User stories describe the purely functional software functions. Before implementation begins, the development team gradually analyses the User Stories and assesses the scope. The advantage of this approach is that the final implementation is only designed when the implementation phase is about to begin. This way, all gained experience and changes to content can be taken into account.

With agile software development you begin with specification documents which used to only contain headings and rough parameters. The rest of the content and all details are constantly updated once development has begun.

User Stories

The basic structure of User Stories is very simple. They consist of a short functional description and acceptance criteria. The functional description usually includes a sentence in this form:

As [roll] I would like [description of function] for [benefit].

 

In a project for developing an application for recording work times, these requirements, for example, could be defined.

 

As department head I would like to be able to see an overview of all
employees in my department in order to be able to complete evaluations.

As an employee I would like to be able to see my working time account
in order to view its current status.

As administrator I would like new employees to be automatically synchronized with the home
directory so that it does not have to be done manually.

When formulating user stories, it is important to make sure that they fulfil the INVEST criteria:

I ndependent:	It must be possible to implement the User Story independently from other stories.
N egotiable:	It must be possible to be able to change the User Story right up until the beginning of the implementation phase.
V aluable:	The user story must have a benefit.
E stimatable:	It must be possible to estimate the scope of implementation of the User Story.
S mall:	User Stories should not be so extensive that it is no longer possible to schedule or prioritise them.
T estable:	The User Story is described in such a way that it is possible to create tests for it.

The functional description is nowhere near sufficient to fulfil the INVEST criteria. Therefore, User Stories are added to so-called acceptance criteria. This way, both functional and technical requirements can be indicated as acceptance criteria. For the user stories mentioned above, these acceptance criteria could be stated, among others:

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.