Happy Birthday, User Story!

A Promise for Conversation, oder: Happy Birthday, User Story!

User Stories sind in der Softwareentwicklung nicht mehr wegzudenken. Als Beschreibungen aus Sicht des Anwenders rücken sie Sinn und Zweck einer Anforderung in den Fokus – in einer für jedermann verständlichen Sprache. Tatsächlich ist das Konzept inzwischen so etabliert, dass man fast vergessen könnte, dass die User Story 2018 schon 20 Jahre wird. Bei diesem Alter ist es kein Wunder, dass sie bereits verschiedene Looks hinter sich gebracht hat.

Von der leichtgewichtigen Story Card zum Epic-gleichen Wochenfüller

Als die User Story 1998 auf die Welt kam, war sie in der Tat ein Kleinkind, leichtgewichtig, hieß noch Story Card und enthielt keine technischen Details. Stattdessen sollte ein Entwickler mit Fragen zu einem späteren Anwender gehen, und mit diesem direkt reden. Alistair Cockburn prägte am Rande eines Projektes bei Chrysler dabei den griffigen Satz, dass eine solche Story Card „a promise for conversation“ sei.

Der auf direkte und regelmäßige Kommunikation ausgerichtete Ansatz entwickelte sich rasch weiter. Im Extreme Programming (XP) war die User Story im Rahmen des Planning Games beinahe ein Epos, dessen beispielhafte „ideale Entwicklungszeit“ mit 1 bis 3 Wochen angegeben wurde. Bei weniger als einer geschätzten idealen Woche wurde empfohlen, Stories zusammenzufügen. Auch als 2003 die INVEST-Kriterien formuliert wurden, waren Stories von mehr als einer Woche Länge noch der Regelfall.

Und zurück: Kleine User Stories = weniger Missverständnisse

Inzwischen geht der Trend wieder in die entgegengesetzte Richtung. Es gilt, dass eine gute User Story von einem Team an einem Tag umsetzbar sein soll, beziehungsweise dass sie in iterativen Projekten nicht mehr als 10 Prozent der Gesamt-Velocity eines Sprints umfassen sollte. Tatsächlich zeigt sich im Projektalltag häufig, dass kleinere und dadurch übersichtlichere User Stories von allen Beteiligten leichter verstanden und gehandhabt werden. Kleinere Stories führen dadurch nicht selten zu einer höheren Velocity. Trotzdem trifft man immer wieder auf als Miniaturkonzepte ausformulierte User Stories mit detaillierten Akzeptanzkriterien, die mehrere Seiten umfassen. Wenn es dann auch nicht mehr für nötig erachtet wird, sich fortlaufend mit dem Endnutzer über den Inhalt auszutauschen, führt das das Konzept des Versprechens einer Konversation natürlich ad absurdum.

Um solchen Entwicklungen vorzugreifen, entstand schon 2001 das bekannte Muster „Role – Feature – Benefit“: ‚Als Anwender möchte ich eine Funktion, um damit etwas tun zu können.‘ Gemeinsam mit dem etwa zur gleichen Zeit von Ron Jeffries und Chet Hendricksons formulierten Trio der „3 Cs“, nämlich (Story) Card, Conversation (mit dem Kunden) und Confirmation (durch den Kunden), beschreibt dieses Template griffig das kontinuierliche Einholen von Anwender-Feedback als Leitsatz agiler Software-Entwicklung.

Leider verselbständigte sich das Konzept User Story trotzdem und bildete Rumpfversionen aus, die nur noch Anforderungen, aber keine Gründe benannten. Es mag auch nicht geholfen haben, dass sich User Stories damit einer populären literaturtheoretischen Definition von „story“ annäherten. Hier gibt es die zwei Begriffe „Story“ und „Plot“. Story und Plot unterscheiden sich dadurch, dass nur letzter die Begründung für eine Sequenz von Ereignissen liefert, während die Story die Kausalität aus Gründen der Dramaturgie verschweigt. Der Schriftsteller E. M. Forster formulierte das Beispiel (zum Beispiel in dieser Quelle):

„The king died and then the queen died” is a story. But ‘“the king died and then the queen died of grief” is a plot.“

User Plot: die Begründung hält Einzug

Nach dieser Logik sollte die User Story in ihrer häufigsten Form also wohl besser User Plot heißen. Denn bei der Formulierung von Benutzeranforderungen geht es um genau diese Begründung, nämlich die Begründung des Anwenders, warum er eine bestimmte Funktionalität haben will – eine Begründung, die jeder Endnutzer im direkten Gespräch irgendwann nennen sollte.

Damit das ‚Warum‘ nicht mehr unter den Tisch fällt, hat sich inzwischen eine Formulierung etabliert, die die Begründung ganz an den Anfang stellt: „Um etwas zu erreichen, möchte ich als Anwender eine bestimmte Funktionalität.“ Natürlich kann man auch solche User Stories noch zu überlangen Epen aufblasen, aber zumindest das Überleben des Kundenwunsches in der Formulierung scheint auf diese Weise ebenso gesichert wie das Überleben des Konzeptes selbst.

Auf die nächsten 20 Jahre!

Die dafür nötige Wandlungsfähigkeit hat die User Story bislang ja eindrucksvoll unter Beweis gestellt. Ein Aspekt sollte bei allen Wandlungen unbedingt erhalten bleibt: der Merksatz, dass eine User Story letztlich nur ein Versprechen ist, dass noch eine Unterhaltung mit einem Anwender stattfindet.

---

[1] INVEST steht für

• Independent = die fachliche Unabhängigkeit
• Negotiable = über ihren Inhalt kann und soll diskutiert werden
• Valuable = sie stiftet Mehrwert
• Estimable = sie kann geschätzt werden
• Small = klein und
• Testable = kann getestet werden

---

Über den Autor