In Scrum oder anderen agilen Methoden werden User Stories eingesetzt, um ein gemeinsames Verständnis von Anforderungen zu bekommen. Mit einer alltäglichen Sprache werden Ziel und Nutzen transparent. Sie sind damit ein bewährtes Mittel um strukturiert und fokussiert zu arbeiten. Als Produktdokumentation sind sie aber eher ungeeignet. Warum ist das so?
Sie sind aus der agilen Entwicklung kaum noch wegzudenken. User Stories bestehen nur aus maximal zwei Sätzen und Ziel des Refinements ist es, diese Stories möglichst klein und unabhängig zu schneiden. Durch ihren kurzen und klaren Aufbau kann man schnell die relevanten Informationen für den anstehenden Sprint ablesen.
Als <Nutzer>
möchte ich <Ziel>,
damit ich <Nutzen> habe.
Durch diese kompakte Darstellungsweise bieten sie dem Entwicklerteam einen großen Lösungsraum. Gerade in bestehenden Systemen mit vielen Abhängigkeiten werden deshalb auch Akzeptanzkriterien angewandt, z.B. auf der Rückseite der Story-Karte. Es soll klar werden, unter welchen Voraussetzungen, bestimmte Bedingungen erfüllt werden müssen, um die Story zur Zufriedenheit der Stakeholder abzuschließen. Es empfiehlt sich, dass die Kriterien von dem User-Story-Schreiber und dem Tester im Team, gemeinsam beschrieben werden. User Stories mit Akzeptanzkriterien sind eine gute Kombination, um ausreichend Informationen für den anstehenden Sprint zu haben. Sie eignen sich damit gut als Projektdokumentation, die dennoch genug Freiheiten und Flexibilität lässt.
Spätestens jetzt könnte man glauben, dass User Stories ausreichen würden, ein Produkt damit zu beschreiben. Aber schauen wir uns die folgenden drei Aspekte bzgl.User Stories genauer an:
- Verwaltung
- Granularität
- Zeitpunkt
User Stories werden in vielen Teams auf Post-its geschrieben und im Team-Raum an die Wand geklebt. Ist der Sprint vorbei, werden sie abgehängt und dann … abgeheftet? Das müsste man zumindest, wenn sie als Dokumentation archiviert werden sollten. Ich gebe zu, dass man hier Lösungen für diesen Verwaltungsaufwand einfach finden kann. Hat man die Stories z.B. digital in einem Tool wie JIRA, können sie auch noch nach Sprintende über die Suchfunktion gefunden werden und nehmen keinen Platz im Team-Raum weg.
Allerdings gibt es in der Regel sehr viele kleingeschnittene User Stories, die aufeinander aufbauen. Sie ändern oft das in vorangegangenen Sprints definierte Softwareverhalten entscheindend. Möchte man wissen wie ein System aktuell funktioniert, müsste man somit alle User Stories der Reihe nach durchlesen und vergleichen. Betrachten wir diesen Umstand mit einem Beispiel aus dem Alltag, wird die Problematik deutlicher.
Jeder von uns hat ein Konto, auf dem sein Gehalt eingeht, die Miete abgeht oder hin und wieder mal ein größerer Betrag für ein unwiderstehliches Angebot auf mydealz verschwindet. Diese Kontenbewegungen können wir mit User Stories gleichsetzen. Jede einzelne Story verändert unser Produkt „Kontostand“. Die User Stories gehören dabei zum Epic Gehalt, Miete oder Lebensunterhalt. Aber schauen wir uns nun jeden einzelnen Kontoauszug an, um zu wissen wie viel Geld wir haben? Wohl kaum und genauso mühsam wäre es auch, sich User Stories anzuschauen, um zu wissen wie das Produkt funktioniert.
Lasst uns zurück zur Software-Entwicklung gehen. Anders als bei Kontoauszügen werden User Stories und deren Akzeptanzkrtiereien vor der Entwicklung geschrieben und bilden damit nicht unbedingt die Wahrheit ab. Während der Implementierung können Entscheidungen anders getroffen worden sein. Es bietet sich daher an, Dokumentation von funktionierender Software und nicht von Konzepten bzw. Anforderungen in Form von User Stories zu machen.
All das zeigt, dass für eine geeignete Produktdokumentation ein anderer Weg bestritten werden muss. Egal, ob man JIRA nutzt oder das Sprintboard an der Wand im Teamraum abbildet, die Produktdokumentation sollte in einem Tool stattfinden, dass man stetig weiterschreiben und versionieren kann. In vielen Fällen ist das ein Wiki und in den vielen Fällen ist es Confluence, das gut mit JIRA verknüpft werden kann. Eine User Story kann also hervorragend als Projektdokumentation genutzt werden, aber in der Produktdokumentation ist sie bestenfalls als zusätzliche Inputquelle für nützliche Informationen geeignet. Sie ist eigentlich ein Wegwerf-Produkt.
Refrenzen
Agile Dokumentation 