Die Userstory ist von zentraler Bedeutung in Scrum. Userstories beschreiben die Anforderungen an das System. Der Scrum-Guide gibt jedoch keine Vorgaben über deren Form oder Inhalt. Das bietet viel Raum für Interpretationen, Missverständnisse und im schlimmsten Fall zur Perversion ihrer eigentlichen Intention. Über nichts wird soviel gesprochen, gestritten und philosophiert wie über die Userstory — und das ist auch gut so, denn dafür ist sie da!

In diesem Artikel beschreibe ich was aus meiner Sicht eine gute Userstory ausmacht und wie man sie schreibt. Ich versuche damit insbesondere Einsteigern in die agile Entwicklung einen möglichst unverkrampften und einfachen Zugang zur Userstory zu geben.

tl;dr

Eine Userstory ist nicht mehr als ein Versprechen des Teams sich zu unterhalten und ein gemeinsames Verständnis für eine Anforderung zu schaffen. Vor diesem Hintergrund gibt es daher auch kein Richtig oder Falsch, sondern nur Stories, die besser oder schlechter für diesen Zweck geeignet sind. Sie sind ein Werkzeug zur Kommunikation.
Es gibt Hilfsmittel, deren Anwendung zu besseren Userstories führen kann. Letztlich ist es aber egal, wie eine Userstory entstanden ist — Was immer für das Team funktioniert dieses Verständnis zu erhalten ist erlaubt und gut. Frei nach dem Agilen Manifest: Individuen und Interaktionen über Prozesse und Werkzeuge.

Was macht eine gute Userstory aus?

Eine Userstory ist ein Werkzeug zur Kommunikation. Sie beschreibt eine Anforderung an das System in Form einer Geschichte. Eine solche Geschichte beantwortet die folgenden Fragen:

1. Welcher neue Nutzen/Wert soll geschaffen werden?
2. Für welche Rolle soll dieser Nutzen geschaffen werden?
3. Wie könnte eine mögliche Lösung aussehen (optional)?

Gute Geschichten lassen Bilder in unseren Köpfen entstehen. Und wenn es uns gelingt, eine Anforderung bildlich greifbar zu machen, dann sind wir auf einem guten Weg. Wir denken visuell, daher sind Bilder für uns viel besser als eine einfache Auflistung in Textform geeignet, um eine Anforderung zu verstehen. Der Volksmund sagt nicht umsonst: Ein Bild sagt mehr als tausend Worte.
Geschichten unterstützen das Team ein gemeinsames Bild von der Anforderung zu erhalten. Und genau das ist wesentliche Punkt: Ein gemeinsames Verständnis davon zu erlangen was wer aus welchem Grund in dem System tun will.

Die Qualität der Lösung steigt mit der Klarheit des gemeinsamen Bildes der Anforderung, welches durch die Geschichte entsteht.

Diese Geschichten müssen nicht lang sein, aber sie muss den den nötigen Kontext geben, um lebhafte Bilder in unseren Köpfen entstehen zu lassen.

Grundgerüst zur Formulierung

Die wahrscheinlich am weitesten verbreitete Form, wie Userstories formuliert werden lautet: “As a < type of user >, I want < some goal > so that < some reason >”. Dieses Format ist auch bekannt als das “role-feature-reason-Format”, welches 2001 bei der Firma Connextra (UK) entwickelt wurde.

Ich halte diese Form der Formulierung jedoch aus mehreren Gründen für problematisch:

1. Sie beschreibt eine neue Eigenschaft des Systems als Ziel der Userstory. Das mag auf den ersten Blick sinnvoll klingen. Aber. Wir erstellen keine Eigenschaften Ihrer selbst Willen, sondern immer aus dem genannten Grund heraus. Wir sind nicht am Ziel, wenn wir die neue Eigenschaft hergestellt haben. Wir sind am Ziel wenn diese neue Eigenschaft auch seinen Zweck erfüllt und der Nutzer sein Problem lösen kann. Nur dann schaffen wir einen Wert.
2. Sie nennt den Zweck wofür wir die Lösung erstellen als Letztes. Damit rückt das Wichtigste ans Ende des Satzes und fristet sein Dasein im Nebensatz als schnödes Beiwerk.

Ich schlage daher folgende alternative Form vor:

Als <Rolle> möchte ich <Nutzen>. Dazu schlage ich <Lösung> vor.

Ein Beispiel: “Als Koch möchte ich alle Gäste ordentlich nacheinander bedienen können. Dazu schlage ich eine nach Zeitpunkt der Bestellung sortierte Liste der Bestellungen” vor.

Hier stehen die beiden wichtigsten Dinge am Anfang. Welchen Nutzen möchte ein Nutzer in seiner Rolle erhalten? Erst danach folgt die dazu (hoffentlich) geeignete Lösung. Die Lösung ist zudem auch optional, so dass man die Userstory auch einplanen kann ohne zu wissen, wie eine mögliche Lösung aussehen könnte.
Diese Form der Userstory ist auch besser geeignet damit der PO die Stories im Backlog nach ihrem Wert priorisieren kann. Siehe hierzu auch “Ein Product Backlog ohne Rauschen”

Neben dieser Formulierung gibt es übrigens noch weitere Formen, die ich euch an dieser Stelle nicht vorenthalten will.

Der Nutzen

Welches Problem soll gelöst werden? Welchen neuen Nutzen bekommt der Anwender, wenn die Userstory umgesetzt ist? Das ist die zentrale Frage die in einer Userstory beantwortet werden muss. Die Antwort ist die Grundlage, auf der wir eine Lösung erstellen, und der Maßstab, an dem wir bewerten, ob die Story einen Wert generiert.

Die Rolle

Die Rolle ist der einfachste Teil bei der Formulierung einer Userstory. Die Rolle beschreibt wer die Anforderung hat. Je spezifischer die Rolle ist, umso besser. Angaben wie “der Nutzer” sind zu vermeiden. Es gibt nicht den Nutzer. Es gibt nur echte Menschen, mit echten Problemen, für die wir eine Lösung erstellen wollen.

In der Praxis werden zur Spezifizierung der Rollen häufig Personas verwendet. Aus meiner Erfahrung kann ich sagen, dass diese Personas sehr hilfreich sind. Der Mehraufwand für das Erstellen lohnt sich!
Personas hauchen der Rolle Leben ein und erlauben es, uns sich in ihre Sichtweise zu versetzen. Aus dieser Perspektive können wir viel besser beurteilen wie gut Ideen zur Lösung funktionieren werden.

Die Lösung

Die Lösung beschreibt primär durch was der Nutzen generiert wird. Sie macht einen Vorschlag, welche Eigenschaft das System nach der Umsetzung aufweisen könnte, um den Nutzen zu generieren.

Die Lösung ist im Gegensatz zum Nutzen immer verhandelbar. Aus diesem Grund ist sie als Vorschlag formuliert. Das führt aus meiner Sicht zu zwei Dingen: Zum Einen wird der Vorschlag eher hinterfragt. Führt dieser Vorschlag tatsächlich zu dem gewünschten Nutzen? Zum Anderen lässt es dem Team die Freiheit, alternative, vielleicht bessere, Vorschläge zu machen.

Dadurch, dass wir in dem Lösungsvorschlag nur das was aber nicht das wieformulieren, öffnen wir den Lösungsraum für das Team, so dass dieses möglichst unvoreingenommen die bestmögliche Lösung finden kann. Daher halte ich die Formulierung einer Lösung auch für optional.

Gut zu wissen

Im Laufe der Zeit habe ich einige Erfahrungen mit Userstories gemacht und diese möchte ich hier gerne teilen. Vielleicht ist der ein oder andere Punkt dabei, der euch bei der Erstellung helfen kann.

Ist die Geschichte für den Nutzer erlebbar?

Meine Empfehlung ist Userstories immer so zu formulieren, dass das Ergebnis dieser Geschichte für einen Nutzer erlebbar sein kann. Die Geschichte soll für den Nutzer einen wirklichen Outcome haben und einen echten Nutzen bringen oder ein Problem lösen. Warum ich das so wichtig find, habe ich in “Ein Product Backlog ohne Rauschen” beschrieben.

INVEST

Wie kann ich entscheiden, ob ich eine gute Userstory geschrieben habe? Also eine Userstory, die a) zu einem gemeinsamen Verständnis führt und b) in einem Sprint auch mit hoher Wahrscheinlichkeit zu einem wertschaffenden Ergebnis führt. Natürlich gibt es hier keine allgemein gültige Antwort, aber es gibt ein Hilfsmittel, welches ich empfehlen kann, und welches bei der Beantwortung helfen kann: Das INVEST Modell von Bill Wake.

Es erlaubt anhand von 6 Kriterien eine User-Story zu überprüfen.

• “I” ndependent (von allen anderen)
• “N” egotiable (die Lösung ist nicht fest)
• “V” aluable (oder auch vertikal, kommt von vertikalen Durchstich)
• “E” stimable (mit einer “guten” Annäherung)
• “S” mall (passt in einen Sprint)
• “T” estable (prinzipiell testbar)

Wenn alle Kriterien erfüllt sind, dann sind wir schon auf einem guten Weg. Zumindest können wir uns ziemlich sicher sein, dass wir formale Anforderungen an die Userstory erfüllen.

Akzeptanzkriterien

Zusätzlich zu der ausformulierten Geschichte kann eine Userstory weitere, spezielle Anforderungen enthalten. Diese werden gesondert aufgelistet, da sie sich nicht direkt aus der Geschichte ergeben. Diese Anforderungen bilden Kriterien für die Akzeptanz der fertigen Lösung und können sowohl funktional als auch nicht-funktional sein. Ein Beispiel wäre die Notwendigkeit, dass die Lösung eine bestimmte Norm oder Spezifikation erfüllen muss.

Wie groß sollte eine Userstory sein?

Es gibt keine genaue Regel, die besagt wie groß eine Story sein sollte. Aber es gibt mindestens eine Rahmenbedingung: Das Team muss in der Lage sein diese Story innerhalb eines Sprints zu erledigen.

Große Stories sollte man versuchen aufzuteilen. Sie bergen das Risiko rechtzeitig zum Ende des Sprints fertig zu werden und so keinen Wert generiert zu haben. Das wollen wir vermeiden. Aber in manchen Fällen ist das nicht möglich.

Wir versuchen eine Geschichte zu “zerschneiden”, indem wir aus einer Geschichte zwei oder mehr Geschichten machen. Einzige Bedingung hierfür ist, dass jede Geschichte für sich einen Wert für den Anwender generiert. Hilfreich ist hier ein Blick auf das INVEST-Modell (siehe oben).

Bitte nicht!

Userstories sind keine detaillierten Anforderungsdokumente und keine Anleitungen was wie genau in kleinteiligen Schritten umgesetzt werden soll. Sie sind keine Spezifikation der Umsetzung!

Hierfür gibt es aus meiner Sicht zwei Gründe:

1. Eine Userstory in dieser Form zu schreiben würde eine genaue Planung voraussetzen. Das impliziert ein genaues Wissen über das gewünschte Ergebnis und über den Weg dahin inklusive des gesamten Kontexts, in dem sich die Geschichte abspielt. Software Entwicklung spielt sich in der Regel in einem Umfeld ab, in dem genau diese Voraussetzungen nicht gelten. Eine solche vorherige Planung wird scheitern. Spart euch den Aufwand. Es ist Muda, was soviel heisst wie vertane Zeit.
2. Das Team trägt die Verantwortung für die Qualität der Umsetzung der Userstory. Das umfasst sowohl die technische Exzellenz, die Benutzbarkeit und das Aussehen. Wir wollen die Expertise für diese Bereiche in unserem Team heben und nutzen und nicht durch genaue Spezifikationen einschränken.

Es gibt Rahmenbedingungen, die dazu führen, dass eine Userstory sehr kompliziert formuliert wird. In der Regel lassen sich diese Bedingungen jedoch als Akzeptanzkriterium formulieren oder ggf. auch in die Definition Of Done aufnehmen.

Eine vollständig spezifizierte Userstory wäre eine Perversion ihrer eigentlichen Intention: Das Team ins Gespräch zu bringen, um gemeinsam an der besten Lösung zu arbeiten. Warum sollte sich das Team über die Lösung unterhalten, wenn schon alles genau spezifiziert und in Stein gemeißelt ist?