Es gibt unzählige Ansichten, Meinungen und “Standards” zum Begriff der User Story. Selbst die Anfänge der 3Cs aus dem Pleistozän agiler Entwicklung enthalten noch viele nützliche Konzepte und Gedanken hierzu.

Dabei wird aber manchmal vergessen, dass das meiste Konventionen sind, die jedes Projekt oder jedes Team für sich jeweils ändern kann, wenn es das für richtig hält. Allerdings hat sich in den letzten Jahren eine Art Minimalstandard entwickelt, der eine User Story (US) mindestens genügen muss, um zu funktionieren. Dieser Minimalstandard beschränkt sich auf wenige Grundsätze und ist für viele Projekte ausreichend.

Okay, zugegeben, ich selbst habe den hier vorgestellten Minimalstandard in der Vergangenheit auch nicht immer eingehalten. Aber im Laufe der Zeit habe ich eingesehen, dass der kleine Mehraufwand, das kleine Stück mehr an Disziplin sich lohnt. Die Qualität der US ist am Ende besser und das Team zufriedener.

Über den Minimalstandard hinaus gibt es verschiedene, optionale Merkmale einer US, für die sich ein Team oder ein Projekt bewusst entscheiden und dies idealerweise auch schriftlich dokumentieren sollte – z.B. in den DoD (Definition of Done) oder DoR (Definitio of Ready). Es ist wie beim Eiskunstlaufen, es gibt eine Pflicht und eine Kür.

Die Pflicht

Die User Story besteht nur aus einem Satz

Nimmt man den Begriff User Story zunächst wörtlich, dann hat man schon den Kern der damit einhergehenden Idee erfasst. Es geht um die Anforderung eines Nutzers oder eines Anwenders, der etwas an dem System, das er zur Erledigung seiner Aufgaben benutzt, vermisst oder verbessert haben möchte. In der Regel drückt der Anwender seine Anforderung in einfacher (fachlicher) Umgangssprache aus, zum Beispiel: Auf der Einstiegsseite der Anwendung möchte ich eine Ampel sehen, die mir den Zustand des Systems anzeigt. – dies ist Teil einer Satzschablone.

Die Nutzer wissen in der Regel am besten, wie eine Anwendung verbessert werden kann. Daher spielen die von den Nutzern, oder stellvertretend vom Product Owner (PO), formulierten User Stories eine zentrale Rolle in der Softwareentwicklung. Die Formulierung fällt den Nutzern leicht und ist auch für andere Team Mitglieder in der Regel verständlich. Eine US muss sich in einem Satz formulieren lassen. Aus dem zweiten, dritten und vierten Satz werden die zweite, dritte und vierte US.

Die US benennt die Rolle des Nutzers

Selbst in einfachen Systemen gibt es üblicherweise mindestens zwei Rollen: die des Nutzers und die des Administrators. Daher sollte die US die Rolle klar benennen. Als Standard hat sich eingebürgert dies gleich am Satzanfang zu tun: Als Administrator möchte ich eine Ampel sehen…

Die US enthält eine Begründung / den Nutzen

Weil Entwickler normalerweise keine Fachexperten auf dem Gebiet der Nutzer sind, brauchen sie mehr Informationen, um die Zusammenhänge und Hintergründe verstehen zu können. Daher wird eine gute User Story immer einen solchen Kausalzusammenhang mit formulieren, im obigen Beispiel etwa: …eine Ampel sehen, damit ich mir den Anruf beim Support sparen kann.

Dieser Hinweis hilft den Entwicklern zu verstehen, warum die Verbesserung gewünscht ist. Andererseits wird auch der Nutzer angehalten, sich über die Sinnhaftigkeit der eigenen Anforderung Gedanken zu machen. Eine gut formulierte Begründung eröffnet auch die Gelegenheit über Alternativen zu diskutieren, die den gleichen gewünschten Nutzen auf andere, möglicherweise kostengünstigere Art erreichen.

Die US hat Akzeptanzkriterien

Jede US sollte eine Liste von Bedingungen enthalten, die erfüllt sein müssen, damit der Nutzer (oder stellvertretend der PO) die Umsetzung akzeptiert. Diese Liste der Akzeptanzkriterien kann als Detaillierung der eigentlichen US verstanden werden. Sie gibt den Entwicklern wertvolle Hinweise über den Umfang der US und wird damit oft zum Verhandlungskriterium, ob eine US zu groß ist und noch weiter unterteilt werden muss.

Für das Beispiel könnte das so aussehen:

• Die Ampel zeigt Grün, wenn keinerlei Störung vorliegt

• Die Ampel zeigt Gelb, wenn Einschränkungen bestehen

• Die Ampel zeigt Rot, wenn das System komplett ausgefallen ist

• Wenn die Ampel auf Gelb oder Rot steht, muss eine zusätzliche Information über die Ursache angezeigt werden

• Wenn die Ampel auf Gelb oder Rot steht, muss die voraussichtliche Dauer der Störung angezeigt werden

Die beiden letzten Kriterien hätte man umgangssprachlich auch mit „und“ verbinden können. Gute Akzeptanzkriterien sind aber möglichst unabhängig zu formulieren, d.h. jedes Kriterium steht als eigener Punkt in der Liste. Das hat den Vorteil, dass die einzelnen Punkte leichter verhandelbar sind. Man könnte zum Beispiel entscheiden, dass man die Anzeige der geschätzten Dauer in eine eigene US verpackt, da die ursprüngliche sonst zu groß würde. Ja, man hätte auch noch jede der beiden letzten Kriterien in jeweils ein eigenes Kriterium für Gelb und Rot verpacken können. Die Entscheidung, wann man unterteilt oder eben nicht, ist oft das Resultat einer Diskussion im Team.

Die Kür

Bei komplexeren Projekten bieten sich Formalisierungen und Erweiterungen des Minimalstandards an. Damit verlässt man aber auch oft die Einfachheit der normalen Nutzersprache, der Aufwand die US zu schreiben erhöht sich und verlangt allen Beteiligten mehr Disziplin bei der Formulierung ab.

Satzschablonen

Eine gleichbleibende Qualität und Vergleichbarkeit von Anforderungen kann durch vorgegebene Satzschablonen erreicht werden. Diese sind dann verbindlich für die Formulierung jeder Anforderung einzuhalten. Die Schablone kann beinahe jede Form annehmen, die für das jeweilige Projekt geeignet erscheint. Die minimale Satzschablone wäre also: Als Rolle X möchte ich Y, weil ich so den Vorteil Z habe.

Modalverben und Glossar

Um begriffliche Unklarheiten so gering wie möglich zu halten, kann man eine verbindliche Definition der Modalverben (muss, kann, sollte) festlegen. Ein allgemein anerkannter Standard zu englischen Modalverben ist in RFC 2019 definiert. Idealerweise wird dies mit einem abgestimmten Glossar für die Entitäten kombiniert. Die Begriffe, die in den US verwendet werden, folgen dann der im Glossar definierten Bedeutung.

Zusätzliche formale Anforderungsbeschreibungen

Um die Eindeutigkeit und Klarheit komplexer Systeme und Anforderungen zu steigern, bieten sich in erster Linie die verschiedenen Diagramm Typen aus der UML-Modellierung an.

Einordnung in einen Kontext

Zahlreiche weitere Hilfsmittel stehen zur Verfügung, um die Beschreibung der US zu ergänzen und in einen Kontext einzuordnen. Hier seien nur ein paar der gängigsten genannt: Story Map, Personas, Roadmap, Stakeholder Listen.

Qualitätskriterien

Man kann jede US auch nach bestimmten qualitativen Kriterien bewerten und erst dann für die Entwicklung freigeben, wenn diese erfüllt sind. In agilen Projekten definiert man hierzu projektspezifische Kriterien, die sogenannten DoR – eine Liste von Bedingungen, die geprüft wird, bevor eine US für die Entwicklung freigegeben wird – und damit verwandt die DoD – eine Liste von Kriterien, die zusätzlich zu den US-spezifischen Akzeptanzkriterien geprüft wird. Ein anderes sehr gängiges Beispiel für Qualitätsanforderungen an User Stories ist INVEST.

Obwohl die DoR und DoD häufig anzutreffende Kriterien sind, die für User Stories benutzt werden, sind diese nicht immer so nützlich wie man glaubt. Im Gegenteil können sie zu einer Bürokratisierung führen, die dem agilen Geist entgegensteht. Ich gebe zu, dass dies eine kontroverse These ist. Aber reicht als DoR nicht aus, dass die Story in einen Sprint passt? Und führen uns ellenlange Listen nicht zum Wasserfall zurück? Denken wir darüber mal nach.