Karteikarten und Bierdeckel - Wie schreibt man gute User Stories?

von Ann-Cathrin Mackenthun , Anne Hoffmann am 25. September 2012

In der agilen Software-Entwicklung werden Anforderungen nicht mehr in Pflichten- und Lastenheften geschrieben, sondern in Form von handlichen User-Stories festgehalten, die auf einer Karteikarte oder einem Bierdeckel Platz haben. Doch wie schreiben Sie kurze und knackige Anforderungen, die nützlich für die Entwickler sind und eine gute Basis für aufgabenorientierte Dokumentation darstellen?

Scrum, Sprints und Inkremente

Die Verwendung von User Stories als Anforderungsbeschreibungen für die Software-Entwicklung geht auf agile Entwicklungsverfahren wie Scrum zurück. Ein nach Scrum geführtes Projekt wird nicht von Anfang an durchgeplant. Stattdessen arbeiten die Entwickler in kurzen Entwicklungszyklen, Sprints genannt. Zudem werden nur kleine und in sich geschlossene Funktionen (Inkremente) entwickelt, z.B. eine neue Schaltfläche mit einer Druckfunktion. Diese Inkremente bestehen aus allen notwendigen Einzelbestandteilen, wie z.B. Datenbankanbindung, funktionalem Code und Oberfläche. Theoretisch kann die Software am Ende jedes Sprints mit den neuen Funktionen ausgeliefert werden.

Inkremente Softwareentwicklung — Inkremenente Softwareentwicklung

User Stories

Die Definition von Anforderungen in Scrum unterscheidet sich deutlich von anderen, herkömmlichen Entwicklungsmethoden. Bei der Definition der Anforderungen wird der Nutzer in den Mittelpunkt gerückt. Die User Stories beantworten dem Entwickler kurz und knapp die wichtigsten Fragen: Wer braucht warum welche Funktion? Für das Beispiel mit der Druckfunktion könnte die User Story folgendermaßen lauten: „Als Labor-Mitarbeiter möchte ich die grafische Darstellung des Ergebnisses der Untersuchung 3aXX direkt aus dem Grafik-Dialog heraus drucken können.“

Kryptische Notizen

Was sich so einfach liest, ist im Alltag der Software-Entwicklung nicht immer so einfach umzusetzen. Oft wird ein Teil der Informationen weggelassen, weil „das macht eh Kollege Meier, der weiß schon, was gemeint ist“. Oder das Team schreibt direkt die technische Umsetzung auf, etwa „auf Graf_008erg noch print_graf3 einbinden“. Doch nicht immer werden solche Anforderungen sofort umgesetzt, die Software entwickelt sich mit jedem Sprint weiter und nach ein paar Wochen weiß keiner mehr, was mit solch einer kryptischen Notiz gemeint war.

Gute User Stories schreiben

Um dem vorzubeugen, helfen einfache Eselsbrücken. Im ersten Schritt wendet man das Formulierungsmuster [MC] an: Als [wer] möchte ich [welche Funktion] damit ich [warum]? Die drei „W‘s“ sind einfach zu ersetzen. Die genaue Form ist dabei nicht entscheidend, wichtig ist, dass die Informationen enthalten sind. Etwas detaillierter sind die INVEST-Kriterien für Anforderungen [BW]:

I – Independent: Ist es eine in sich geschlossene und von anderen Anforderungen unabhängige Anforderung?

N – Negotiable: Weiß ich als Entwickler, was der Nutzer braucht, und kann somit verschiedene Lösungen für die technische Umsetzung verhandeln?

V – Valuable: Ist diese Funktion wirklich wichtig? Hat sie einen Geschäftswert?

E – Estimatable: Kann ich für diese Anforderung abschätzen, wie lange ich brauche? Liegt die Zeitschätzung unter 2 Tagen?

S – Small: Ist es wirklich das kleinstmögliche Inkrement oder kann ich die Anforderung in mehrere Inkremente aufbrechen?

T – Testable: Kann ich die Umsetzung der Anforderung testen? Welche Angaben fehlen mir, damit ich weiß, was ich testen muss?

Investkriterien in der agilen Softwareentwicklung

Vom Bierdeckel zum Handbuch

Doch warum sind die User Stories, die die Entwickler nutzen, nun für Technische Redakteure interessant? Vor allem, weil sich die User Stories fast allein zu einem aufgabenbasierten Handbuch zusammenfügen. Es ist sofort klar, in welches Handbuch die neu programmierte Funktion gehört, in unserem Beispiel ins Handbuch für Labor-Mitarbeiter. Auch die Tätigkeit, das Ausdrucken, steht schon direkt in der User Story und kann im entsprechenden Kapitel eingefügt werden. Und wenn an anderer Stelle die Durchführung der Untersuchung 3aXX beschrieben ist, kann dort einen Querverweis auf das neue Kapitel mit der Druckfunktion angelegt werden. So einfach war das Handbuch schreiben noch nie.

Vorteile für Dokumentation und Entwicklung

Es lohnt sich sowohl für die Entwicklung als auch für die Dokumentation, wenn die User Stories gut formuliert sind. Die Entwickler können die Funktionen programmieren, die die Benutzer wirklich brauchen, und nicht die, die sie sich sich aus den Informationen zusammenreimen. Und Technische Redakteure profitieren von der aufgabenbasierten Beschreibung der User Story. Wenn Sie als Technischer Redakteur die Abläufe in einem agilen Software-Projekt kennen, können Sie sich gezielt die benötigten Informationen holen. Und wer weiß, vielleicht haben Sie in Zukunft sogar Interesse bei der Formulierung der User Stories zu helfen? Immerhin sind eindeutiges Formulieren sowie das Vertreten der Nutzersicht genau unsere Stärken.