Was sind User Stories?

Unter einer User Story versteht man im Allgemeinen eine Software Anforderung. Das Besondere an ihr ist, dass die Anforderung, die sie stellt, kurz geschrieben ist (maximal zwei Sätze) und einer festen Struktur folgt. Diese Struktur, nach der eine User Story aufgebaut werden soll, folgt einem nutzer-zentrierten Ansatz.

Als [ROLLE] möchte ich [FEATURE], weil [NUTZEN].

Der Name des Begriffes selbst, also User Story, ist hierbei von entscheidender Bedeutung. Anders als beim einfachen Begriff Anforderung steckt im Begriff User Story der User, also der Anwender mit drin. Eine User Story ist demnach eine Anforderung, die direkt vom Anwender selbst kommt und sowohl ihn als auch seine Anliegen in den Mittelpunkt stellt. Diese Tatsache hilft dem Leser der User Story dabei zu verstehen, wer eigentlich hier was möchte und welcher Nutzen daraus erwartet wird.

Eine genauere Definition des Begriffs kann man sich in englischer Fassung hier (leider nicht via HTTPS erreichbar) durchlesen.

Der Sinn und Zweck

Um es in einem Satz auszudrücken: Die User Story verfolgt das Ziel, eine Anforderung zu definieren, die für alle klar verständlich und nachvollziehbar ist und die Funktionalität in den Vordergrund stellt.

Durch die spezielle Formulierung in der User Story wird dadurch hervorgehoben, für wen wir eigentlich die Software schreiben, verbessern und entwickeln. Es hilft ungemein diese Tatsache immer wieder in das Gedächtnis des Produktteams zu rufen, um nicht mit der Zeit der fälschlichen Annahme zu unterliegen, man entwickle die Software um der Software oder des Produktteams Willen.

Gerade in agilen Umgebungen hat sich die User Story ihren Platz gesichert, da sie, richtig angewendet, Konzepte des agilen Manifestes umsetzt. Allen voran: “Stelle die Zusammenarbeit mit dem Kunden höher als Vertragsverhandlungen”.

Woher kommen User Stories?

An dieser Stelle könnte man jetzt auch gerne Fragen: Woher kommen eigentlich diese Anforderungen? Das ist in der Tat eine häufig gestellte Frage und nicht selten ein Problem. Ich habe bereits Unternehmen erlebt, in dem die Anforderungen einfach von oben nach unten durchgegeben werden, mit der Hoffnung, dass die Kunden das schon gut finden würden, was damit geplant ist. Andere Teams messen detailliert das Nutzungsverhalten der Software oder stellen regelmäßige Befragungen ein und leiten davon Anforderungen ab. Wieder andere geben den Anwendern einen direkten Kanal, um Wünsche und Kritiken einzubringen, aus denen dann wiederum User Stories geschnitten werden.

In den meisten Produktteams gibt es eine spezielle Rolle, die das Verfassen und Prüfen von User Stories übernimmt: Der Product Owner. Es gibt jedoch auch Teams, bei denen aus einfach formulierten Anforderungen die User Stories gemeinsam verfasst werden, damit das Verständnis für den Anwender und seine Wünsche verstärkt wird, da man sie ja jetzt selbst mit formuliert.

Wie auch immer eine Anforderung rein kommt: Sie wird (in der Regel) nicht technisch verfasst und zeigt eine Funktion auf, die sich der Anwender wünscht.

Je nach Produkt, Vertriebs- und Community-Kanäle können die Anforderungen also über diverse Schnittstellen an das Produktteam getragen werden, müssen dann jedoch noch in die korrekte Form überführt werden. Wie vielfältig die Kanäle sind, ist von Team zu Team und Produkt zu Produkt äußerst divers und muss individuell angepasst werden.

Die Form der User Story

Nachdem wir jetzt also geklärt haben, was User Stories sind, welche Vorzüge sie haben und wie sie in das Team gelangen, wäre jetzt noch eine wichtige Frage zu klären: Wie sieht eine User Story eigentlich genau aus? Und woran erkenne ich, ob eine User Story gut ist?

Stellen wir uns dazu einmal vor, wir wären das Produktteam einer Blogging Plattform. Nennen wir uns mal … Nedium. Ein Nutzer hat eine Anfrage und äußert eine neue Anforderung an uns. Diese könnte zum Beispiel so aussehen:

Hallo, ich möchte den Text markieren und verändern können.

Eine klassische Anforderung, die man als Software Engineer nur zu oft zu Gesicht bekommt. Hier äußert also irgendjemand den Wunsch, Text in unserer Plattform markieren und verändern zu können. Welche Probleme haben wir als Produktteam jetzt? Naja, zunächst einmal haben wir ggfs. mehrere Stellen, an denen das Markieren und Verändern von Text möglich wäre. Wo möchte der Nutzer das denn jetzt gerne haben? Dann haben wir das Problem, dass wir keine Ahnung haben, an wen sich das Feature richtet. An die Redakteure? An die Leser, die gerne etwas markieren und hervorheben möchten? Zunächst einmal wäre also wichtig zu wissen: Wer ist “ich”?

Als Redakteur möchte den Text markieren und verändern können.

Ahh. Es handelt sich also um den Redakteur. Das hilft uns insofern weiter, als dass wir jetzt eine Rolle vor uns, oder bestenfalls sogar eine definierte Persona, haben, in die wir uns reindenken können. Ein Redakteur ist jemand, der Inhalte erstellt und Text verfasst. Ein Redakteur arbeitet maßgeblich mit unserem Redaktions-Tool. Der kann durchaus ein gewisses Interesse daran haben, Texte zu verändern, aber das kann er ja schon. Einfach Markdown-Notation benutzen, fertig. Wo wäre der Mehrwert für den Redakteur, wenn er das über eine andere Art und Weise ebenfalls machen könnte? Finalisieren wir die Anforderung und machen daraus eine User Story.

Als Redakteur möchte ich Text markieren können, um in der Lage zu sein, schnell und einfach viele Veränderungen (z. B. Text fett oder kursiv) gleichzeitig machen zu können, weil die Arbeit mit Markdown nicht intuitiv ist und viel Zeit in Anspruch nimmt.

Okay, wow. Das sieht ja jetzt komplett anders aus. Mit diesem kurzen Satz haben wir als Produktteam jetzt auf einmal die Möglichkeit, uns Voll und Ganz in den Anfragesteller hineinzuversetzen. Zudem sind wir nun auch in der Position, das Anliegen zu verstehen und das eigentlich Problem auszumachen. Das wird uns als Produktteam enorm dabei helfen, die beste Lösung erarbeiten zu können.

Wie erkenne ich eine gute User Story

Neben der Tatsache, dass eine User Story möglichst kurz und beschreibend sein soll, gibt es eine kleine, aber feine Hilfe, um die Qualität einer User Story zu bemessen. Bill Wake hat am 17.08.2003 einen Artikel verfasst, in welchem er Charakteristika einer guten User Story festhält und diese mit dem Akronym INVEST tauft. Auf diese nehme ich hier bezug.

I - Independent (Unabhängig)
N - Negotiable (Verhandelbar)
V - Valuable (Wertbringend)
E - Estimable (Schätzbar)
S - Small (Klein)
T - Testable (Testbar)

Unabhängig

Mit Unabhängig ist gemeint, dass eine User Story möglichst keine Abhängigkeiten zu anderen Aufgaben oder User Stories besitzt. Sie soll alleine für sich abschließbar machbar sein und nicht von keiner bestimmten Reihenfolge abhängen. Gerade in größeren und komplexeren Architekturen (z. B. in Microservices) ist die Einhaltung dieses Punktes schwierig, da für die Bereitstellung bestimmter Features die Zusammenarbeit mit anderen Softwareteams nötig sein kann (erst wenn Team T Schnittstelle S implementiert, kann Team T’ seine Arbeit aufnehmen). Daher soll hier die Unabhängigkeit nach innen, also innerhalb des selben Backlogs gemeint sein und nicht die Unabhängigkeit in andere Teams und deren Backlogs.

Verhandelbar

Der dritte Satz des agile Manifestos sagt:

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen

Das ist wichtig, denn eine User Story ist kein fixer Vertrag, kein “must have”, der unter allen Umständen irgendwie implementiert werden muss. Eine User Story soll verhandelbar sein. Sie ist zunächst nur eine Anfrage und die Aufgabe des Produktteams ist es, dieser Anfrage, sofern sie sinnvoll ist und in das Produktkonzept passt, mit Respekt und Offenheit zu begegnen. Es gibt immer mehrere Seiten bei einem Feature zu berücksichtigen: Code, Konzept, Produktentwicklung, Kosten, Mehrwert. Verhandelt werden die besten Lösungen, um das möglichst optimale Ergebnis zu erhalten.

Schätzbar

Die Erläuterung hierzu ist ganz einfach: Wenn eine Aufgabe nicht schätzbar ist, ist sie nicht überschaubar. Und das bedeutet, dass zu viele Risiken existieren, deren sorgfältiges management nicht gewährleistet werden kann. Ist das der Fall, erheben wir den Status des User Story zu einem Epic oder Milestone, die dann wiederum in mehrere kleinere User Stories geschnitten werden.

Klein

Schätzbar bedingt damit auch, dass User Stories klein sind. Wenn die Anforderung des Kunden in der oben genannten Form (1 - 2 Sätze) irgendwie passen soll, dann kann sie nicht allzu komplex sein. Die Form der User Story erzwingt damit sogar ein stückweit eine gewisse Einhaltung der Größe. Da klein ein relativer Begriff ist, kann ihn jedes Team für sich definieren. In den meisten Teams, in denen ich gearbeitet habe, haben wir uns darauf geeinigt, dass User Stories nicht so komplex sein durften, dass eine allein mehr als eine zwei Wochen Zeit in Anspruch nahm.

Testbar

Auch wenn es der letzte Punkt ist, ist es doch einer der wichtigsten. Meinung des Autors: Code, der nicht getestet ist, darf nicht in den produktiven Einsatz. Um sicherzustellen, dass die Anforderung des Kunden auch im seinen Sinne vollständig implementiert wurde, sollte diese immer auf Korrektheit und Vollständigkeit geprüft werden (sowohl technisch als auch produktbezogen). Aus dem Grund sollte eine User Story immer testbar sein und auch getestet werden.

Fazit

User Stories sind ein elementarer Bestandteil in der Kommunikation vom Kunden/Nutzer einer Software zum Produktteam und zurück. Sie bieten uns die Möglichkeit, die Wünsche und Anforderungen des Nutzers wirklich zu verstehen und diese im Sinne des Nutzers auch umzusetzen.

Ein Produktteam, welches den tatsächlichen Anspruch hat, das Produkt auch für seine Kunden zu bauen, kann mit User Stories einen äußerst einfachen aber effektiven Weg in agile Arbeitsmethoden einschlagen, ohne dabei bestehende Unternehmensstrukturen zu stark zu erschüttern.

Wer mehr über User Stories erfahren möchte, dem empfehle ich den Artikel von Wikipedia und den Artikel von Atlassian.