User Stories sind bekannt dafür, dass sie in agilen Softwareentwicklungsprozessen die schriftlichen Anforderungen an das Softwareprodukt inkarnieren. Diese sind so formuliert, dass sie aus Endnutzersicht den zu erwartenden Wert explizit beschreiben. Sie bestehen meist nur aus einem Satz, der die Kernfunktionalität beschreibt, sowie kleineren Informationen und Akzeptanztests. Es stellt sich also die Frage, ob qualitative Unterschiede bei User Stories eine signifikante Wirkung auf den Entwicklungsprozess haben, so wie es im klassischen Requirements Engineering der Fall ist. Kann eine Qualitätssteigerung in User Stories das Endergebnis verbessern oder Probleme verhindern? Was bedeutet eigentlich Qualität im Sinne von User Stories? Was unterscheidet eine gute von einer schlechten User Story? All dies untersucht der nachfolgende Artikel. Es wird eine Methode vorgestellt, die verschiedene Qualitätsmerkmale einer User Story und entstandene Probleme während eines realen Projektes betrachtet. Mögliche Zusammenhänge zwischen Qualitätsverletzungen und Problemen werden angesprochen. Besonderes Augenmerk liegt hierbei auf der natürlichen Sprache, da dies das Medium ist, mit dem User Stories ihre Anforderungen kommunizieren.

Obwohl der offizielle Scrum Guide von Ken Schwaber und Jeff Sutherland das Wort „User Story“ nicht einmal erwähnt, hat es sich quasi als Standard für die Beschreibung einer Anforderung etabliert. Dies ist insbesondere Mike Cohn zuzuschreiben. Er hat sowohl den Begriff „User Story“ definiert und geprägt, als auch ausführlich durch zahlreiche Bücher und Veröffentlichungen dessen Bedeutung gesteigert. Auch wenn der Scrum Guide jegliche Form an Anforderungen zulässt, ist die User Story in heutigen agilen Softwareentwicklungsprozessen einfach nicht mehr wegzudenken. Die Aufnahme und Verarbeitung von Anforderungen orientiert sich dabei an dem agilen Manifest, welches die Kernwerte agiler Prozesse widergibt. Das agile Manifest beruht auf folgenden einfachen Sichtweisen, welche den Fokus der Wertschätzung widergeben:

• Individuen und Interaktionen über Prozesse und Werkzeuge
• Funktionierende Software über umfassende Dokumentation
• Zusammenarbeit mit dem Kunden über Vertragsverhandlung
• Reagieren auf Veränderung über das Befolgen eines Plans

Es sei dabei angemerkt, dass die Werte auf der rechten Seite zwar auch wichtig sind, allerdings haben die Werte auf der linken Seite eine sehr viel höhere Relevanz und formen somit den Charakter agiler Entwicklungsprozesse. Die Anforderungserhebung in agiler Softwareentwicklung folgt demnach keinen strikten Prozessen, bringt sehr wenig Dokumentation mit sich, funktioniert gut in Kooperation mit dem Kunden und ist offen für Veränderung. Mike Cohn definiert den Aufbau einer User Story wie folgt: „Als Rolle möchte ich Funktionalität, sodass ich Benefit erhalte.“ User Stories tragen die Kundenanforderungen durch die Wertschöpfungskette, beginnend bei Kundenbefragungen, über Implementierung bis hin zum Review. Dabei ist es wichtig, dass User Stories aus Sicht des Endnutzers des Systems beschrieben sind und somit explizit den Wert für den Nutzer kundtun. Mike Cohn erwähnt ebenfalls, dass eine Anforderung nicht nur durch die User Story alleine getragen wird. Denn diese ist nur eine textuelle Beschreibung, die dem Team dazu dient, über die Anforderung zu diskutieren. Durch Gespräche und Diskussionen im Team und mit dem Kunden entsteht die Anforderung so auch in den Köpfen aller Beteiligten. Weiterhin empfiehlt Mike Cohn, der User Story Tests hinzuzufügen, die besagen, wann eine User Story erfolgreich beendet wurde.

Wenn man die vorhandene Fachliteratur bezüglich User Story Qualität konsultiert, wird man schnell feststellen, dass es zum einen nicht viel über dieses Thema zu finden gibt, zum anderen dass die Theorien sich stark ähneln und es einen Konsens über eine kleine Menge an Qualitätsattributen gibt. Dies hängt wohl auch stark damit zusammen, dass agile Prozesse neu sind und viele Veröffentlichungen auf die gleichen Quellen verweisen. Nichts desto trotz kann man die Suche nach Qualitätsausprägungen erweitern und Literatur für klassisches Requirements Engineering mit einbeziehen. Denn diese bietet Unmengen an Theorien und etabliertes Wissen, gerade auch für schriftliche Anforderungen, welche sich für User Stories adaptieren lassen.

Es gilt herauszufinden, inwiefern diese gefundenen Qualitätsattribute den Entwicklungsprozess beeinflussen. Dazu muss ein reales Projekt (Scrum) für mehrere Sprints beobachtet und jede User Story auf Qualitätsverletzungen untersucht werden. Diese Qualitätsverletzungen nennt man Smell, geprägt von Martin Fowler, der das Wort „Smell“ einführte, um sogenannte Bad Practices in Quelltexten zu bezeichnen. Genauer gesagt indiziert ein Smell ein Risiko beziehungsweise eine Unschönheit bezogen auf ihren Kontext (Quelltext, User Story). Die Präsenz eines Smells führt nicht automatisch zu einem Problem, kann aber die Ursache für eines sein. Gibt es demnach eventuell Smells in User Stories, die häufiger mit erkennbaren Problemen in Verbindung gesetzt werden können als andere? Gibt es überhaupt eine kausale Verbindung zwischen Smells und Problemen? Im klassischen Requirements Engineering hat man bereits die Erfahrung gemacht, dass, je früher ein Fehler im Prozess begangen wird und je später er erkannt wird, es umso kostspieliger wird, diesen wieder zu beheben. Es wäre doch ideal, wenn man (sofern dieser Effekt auch für User Stories zutrifft) diesen mit diversen Methoden verhindern könnte.

Ausgehend von der Fachliteratur kann man nun ein Set an Qualitätsattributen zusammenstellen beziehungsweise die dazugehörigen Smells ableiten. Der ISO 29148 Standard schlägt hierzu folgende Beispiele vor, die nach Möglichkeit in Anforderungen vermieden werden sollten: 

• Superlative: schnellste, schönste
• Subjektive Sprache: benutzerfreundlich, gut aussehend • Ungenaue Pronomen: dies, das
• Mehrdeutige Adverbien und Adjektive: fast, wenig, schnell
• Nicht verifizierbare Ausdrücke: mindestens ?? TODO
• Vergleichende Formulierungen: besser als, mehr als • Undefinierte Lücken: falls möglich, angebracht
• Negative Formulierung: Das System darf nicht langsamer sein als

Die oben aufgeführten Kriterien beziehen sich mit ihren Beispielen auf die natürliche Sprache. Sie ist für viele Anforderungen das Trägermedium und dient der Kommunikation der Anforderung unter den Stakeholdern. Sie bietet sich offensichtlich an, da sie einfach zu verstehen und zu übertragen ist (im Gegensatz zu z. B. Formalismen etc.). Aber diese Simplizität ist eben nur dem Umstand zu verdanken, dass Informationen über natürliche Sprache sehr leicht missverstanden und fehl interpretiert werden können. Die oben aufgeführten Beispiele sind also mit einem hohen Risiko verbunden, dass sie Informationen nicht eindeutig kommunizieren. Eine Anforderung an sich soll laut Fachliteratur die folgenden Kriterien erfüllen: 

• Vollständig
• Korrekt
• Eindeutig
• Realisierbar
• Notwendig
• Priorisiert
• Verifizierbar
• Prägnant

Es stellt sich heraus, dass sich tatsächlich einige Ansätze aus dem klassischen Requirements Engineering auch einfach für User Stories übernehmen lassen. Für die natürliche Sprache können vorhandene Qualitätsmodelle verwendet werden, um diese auch auf User Stories anzuwenden. Selbstverständlich werden auch das Wissen und die Theorie der agilen Ansätze bezüglich Anforderungsqualität mit beachtet, bevor ein finales Set an Smells aufgestellt wird, welches für die Untersuchung dann verwendet wird. Bei näherer Betrachtung der vorhandenen Literatur stellt sich heraus, dass verschiedenste Ansätze immer wieder auf zwei Kerntheorien zurückgreifen. Die erste sind die drei Cs, welche für Card, Conversation und Confirmation stehen. Ursprünglich von Ron Jeffries geprägt, hat Mike Cohn die drei Cs durch seine Bücher weit verbreitet. Die drei Cs bilden die Grundlage einer jeden User Story: 

• Card: Die User Story ist auf einer kleinen Karte als Text festgehalten, sodass sie von jedem eingesehen werden kann. Sie kann kleinere Details und Informationen enthalten, falls nötig. Ihre Aufgabe ist es, jeden an die Anforderung zu erinnern, welche durch sie repräsentiert wird. Die komplette Anforderung an sich entsteht ja durch Diskussionen und Gespräche im Kopf der Stakeholder. Sie dient somit als Gesprächsstütze.
• Conversation: Die User Story und ihre zugehörige Anforderung werden verbal vom Kunden an das Entwicklerteam kommuniziert. Dadurch werden unterschiedliche Ansichten über die Anforderung ausgetauscht und es entstehen Ideen. Dies fördert das gemeinsame Verständnis. Die tatsächliche und vollständige Anforderung etabliert sich während dieser Gespräche.
• Confirmation: Eine User Story benötigt einen Mechanismus, mit dem sichergestellt werden kann, dass sie korrekt umgesetzt und beendet wurde. Somit wird ihre Korrektheit bezüglich ihrer Anforderung belegt. Der Nachweis kann in Form von User Akzeptanzkriterien und -tests beschrieben werden und stellt somit sicher, was getan werden musste, damit die User Story richtig umgesetzt wurde.

Man kann hier auf jeden Fall Parallelitäten zu den Qualitätsattributen aus dem klassischen Requirements Engineering erkennen. Card ist äquivalent zu prägnant, notwendig und priorisiert. Confirmation steht für vollständig, korrekt, realisierbar und verifizierbar. Einzig Conversation springt ein wenig aus der Reihe, aber das ist auch nicht verwunderlich, da es fester Bestandteil der Werte aus dem agilen Manifest ist und sich somit nicht wirklich einordnen lässt. Im Folgenden wird daher der Aspekt der Gespräche und Diskussionen außen vor gelassen, da dies zusätzlich zur schriftlichen Anforderungserfassung eine komplett neue Dimension eröffnen würde. Dieser Artikel behandelt die detaillierte Untersuchung von Smells in schriftlichen Anforderungen (Card/Confirmation) in Bezug auf Probleme, in der Hinsicht, hier bereits gute Ergebnisse der Analysen zu erzielen. Natürlich schränkt die Nichtbeachtung der Diskussionen die Aussagekraft ein, dazu wird aber am Ende des Artikels nochmals detaillierter Stellung genommen. Neben der textuellen Form der Anforderung soll hier ebenfalls die Bedeutung von Akzeptanztests (Confirmation) hervorgehoben werden. Es gibt Aussagen, dass nicht testbare User Stories höchstwahrscheinlich schlecht formuliert, zu komplex oder abhängig von anderen User Stories sind. Desweiteren trägt die Formulierung von Tests zu einem besseren Verständnis der User Story bei. Ein Entwickler, der weiß, wie eine User Story getestet werden muss, ist ebenfalls in der Lage, sie zu implementieren. Die zweite Theorie bezüglich Qualitätsattribute in User Stories ist das INVEST Modell, welches unschöne Dinge wie Abhängigkeiten, Komplexität und Verifizierbarkeit behandelt. Es ist ein Akronym für mehrere Qualitätsattribute einer User Story und wurde von Bill Wake eingeführt, um zu verdeutlichen, dass eine gute User Story diese Attribute aufweist. Es steht im Folgenden für:

• Independent: Es gibt keine Abhängigkeit zwischen zwei oder mehr User Stories untereinander. Abhängigkeiten erzeugen Probleme bei der Priorisierung und Schätzung, da sie nicht individuell betrachtet werden können.
• Negotiable: Eine User Story dient als Gesprächsstütze, um Diskussionen über ihre Anforderung zu ermöglichen. Wichtige Details werden hierbei etabliert.
• Valuable: Eine User Story sollte einen Wert oder Nutzen für den Benutzer der Software explizit kommunizieren. Dadurch kann sie leichter priorisiert werden.
• Estimable: Eine User Story muss schätzbar sein, damit sie vernünftig mit in die Planung aufgenommen werden kann. Ist sie dies nicht, liegt entweder fehlendes Domänen-/Technikwissen vor oder die User Story ist zu groß.
• Small: Kurze User Stories können besser geplant oder umgesetzt werden, da sie überschaubarer sind und wenig Abhängigkeiten aufweisen.
• Testable: Eine User Story sollte testbar sein um ihre korrekte Umsetzung zu belegen. Tests weisen ebenfalls auf, wann eine User Story beendet wurde.

Auch das INVEST Modell weist sowohl Ähnlichkeiten zu den drei Cs, als auch zu Qualitätsattributen aus dem klassischen Requirements Engineering auf. Nachdem nun die wichtigsten Punkte aus der Fachliteratur bezüglich Anforderungsqualität zusammengefasst wurden, können diese in Smells klassifiziert werden. Dabei steht ein Smell für eine Verletzung des jeweiligen Qualitätsattributs. Im Folgenden ist ein Vorschlag für User Story Smells ausgearbeitet:

Sprachliche Schwächen: 

• Bedeutung: Die User Story enthält sprachliche Schwächen. Dies sind einzelne Wörter oder Formulierungen, die Mehrdeutigkeit und Fehlinterpretation beim Leser verursachen. Dabei muss der Leser sich nicht einmal über die Mehrdeutigkeit bewusst sein, was großes Potenzial für nicht aufgedeckte Missverständnisse birgt. Sprachliche Schwächen werden durch den Schreibstil des Autors und dessen sprachliche Qualifikationen eingeführt, was zu den verschiedensten Ausprägungen sprachlicher Qualität in User Stories führen kann. Die große Anzahl an Quellen und Stakeholdern sorgt für viel Input in eine User Story, was unter Umständen zu Inkonsistenzen führen kann.
• Indikatoren: Unklarheit, Subjektivität, Optionalität, Mehrdeutigkeit.

Kein Wert für den Nutzer: 

• Bedeutung: Fehlender Nutzungswert verschleiert die wahre Bedeutung der Anforderung. Nutzungswert verdeutlicht die Bedeutung der implementierten Funktionalität, denn diese soll den Wert erschaffen. Der Wert führt bei korrekter Implementierung zur Wertsteigerung der Geschäftsprozesse und somit auch zum Geschäft. Die explizite Angabe des Wertes trägt dazu bei, dass das Ziel der Anforderung explizit formuliert ist. Somit ist der Lösungsspielraum offen und diskutabel. Fehlender Wert in einer User Story führt zu Missverständnissen über die Bedeutung der Funktionalität und kann zu falschen Umsetzungen führen.
• Indikatoren: Fehlendes Rational (= Benefit/Ziel), fehlende Priorisierung, technische User Story, User Story mit Evaluationscharakter.

Nicht testbar:  

• Bedeutung: Eine nicht testbare User Story kann nicht auf ihre korrekte Umsetzung hin überprüft werden, so wie es der Kunde gewünscht hatte. Dies ist bei Unklarheit über die Testausführung oder die Ausführung der umgesetzten Funktionalität der Fall. Solch eine User Story verfügt über keine detaillierten Ausführungen der Testvorgänge. Es herrscht Unklarheit darüber, wie die gewünschte Funktionalität tatsächlich arbeiten soll, da Akzeptanztests in gewisser Art und Weise die Beschreibung vorgeben.
• Indikatoren: Fehlende User Akzeptanztests, fehlendes Rational, technische User Story.

Zu große User Story: 

• Bedeutung: Die umzusetzende Funktionalität und Komplexität einer User Story beeinflussen direkt ihre Größe. Eine zu große User Story weist Komplexitäten und Abhängigkeiten auf. Sie bereitet somit Schwierigkeiten beim Planen und beeinflusst den Entwicklungsworkflow negativ, da sie die Simplizität einer idealen User Story überschreitet.
• Indikatoren: Überdurchschnittliche Anzahl an Tasks, überdurchschnittliche Anzahl an Story Points, fehlende Priorisierung, fehlende Schätzung, Unklarheit über die Umsetzung. 

Nachdem nun ausführlich Smells für User Stories gesammelt und besprochen wurden, werden als nächstes potentielle Probleme mit User Stories betrachtet. Diese können theoretisch während des Scrumprozesses auftreten und Schwierigkeiten verursachen. Es gilt ja nach wie vor herauszufinden, ob die gefundenen Smells einen Einfluss auf das Projekt haben, ob sie Probleme verursachen, und ob deren Absenz demnach dazu beiträgt, dass der Entwicklungsprozess besser verläuft. Für die Sammlung von Problemen wurden verschiedene Scrumprojekte beobachtet und erfahrene Scrum Master und Productowner nach ihrer Meinung befragt. Hieraus ergab sich ein einheitliches Gesamtbild von Problemen, die im Folgenden aufgelistet sind: 

• User Akzeptanztests schlagen fehl
• User Story Demonstration ist nicht erfolgreich
• Mindestens ein Kriterium der Definition of Done kann nicht erfüllt werden
• User Story musste während des Sprints geändert werden
• User Story wurde vom Kunden im Sprint Review abgelehnt
• Mindestens eine Person hat die Anforderung der User Story missverstanden
• User Story mit überdurchschnittlicher Implementierungszeit
• User Story mit überdurchschnittlich falscher Schätzung
• User Story konnte aufgrund von Abhängigkeiten nicht beendet werden
• User Story konnte aufgrund Zeitmangels nicht beendet werden
• Im Sprint Planning gibt es noch offene Fragen an den Kunden bezüglich der Anforderung

Eine Optimierung des Recalls gegen 1 ergibt, dass die signifikanten Indikatoren die folgenden sind: Vagueness (Unklarheit), Weakness (Schwäche), Underreference (Ungenügend referenziert), Underspecification (Ungenügend spezifiziert), Implicity (Implizität).

Das Vorgehen der Analyse erschließt sich in der Theorie als logisch und offensichtlich. Die Anwendung an einem realen Scrumprojekt hat gezeigt, dass die Thematik inhärent komplex ist und die optimalen Ergebnisse bzw. der Idealfall nicht eintrat. Es ist ein Ansatz vorhanden, der in die richtige Richtung geht, nämlich im Vorfeld potentielle Problemquellen zu eliminieren. Nach wie vor ist dies keine Garantie für Problemvermeidung (wie auch im klassischen Requirements Engineering). Es bleibt zu erwähnen, dass das beschriebene Vorgehen an weiteren Projekten evaluiert werden sollte, um mehr Erfahrungswerte zu sammeln. Eventuell sind die hier präsentierten Ergebnisse in anderen Projekten komplett anders, da das Team und der Kunde einen großen Einfluss auf das Resultat haben. Dies kann zum Beispiel der Fall sein, wenn das Team nicht gesprächsbereit ist (Interview bzgl. Probleme) oder Probleme vergessen oder als nicht erwähnenswert eingestuft wurden. Der Kunde könnte Scrum falsch oder gar nicht verstanden haben, wichtiges Kundenfeedback am Ende eines Sprint Reviews kann demnach verfälscht oder gar nicht vorhanden sein. Solchen Problemen kann Abhilfe durch Problemprotokolle/-notizen geschaffen werden. Ein weiterer Ansatz könnte zum Beispiel das Messen der Konversationszeit sein, welche das Team benötigt, um eine User Story zu verstehen (kurz vor dem Schätzen). Vielleicht erzeugt eine User Story mit Smells mehr Aufwand, um sie zu verstehen oder zu schätzen. Bei all den greifbaren Ergebnissen darf ein Aspekt nicht vergessen werden: Scrum funktioniert nur mit Kommunikation im Team. Dieser wichtige Punkt wurde bei den Analysen aufgrund der Vereinfachung außen vor gelassen. Im Vergleich mit dem klassischen Requirements Engineering gibt es für agile Prozesse noch wenig Theorien und Ansätze, die Qualität der Anforderungen zu sichern und zu steigern. Es ist demnach mit Spannung zu erwarten, was weitere Untersuchungen an Ergebnissen liefern werden.