User Story explained

Die Geschichte der User Story ist eine Geschichte voller Missverständnisse...

Mal findet man eine Anforderung als einzelne schwammige Textzeile formuliert, in der wohl das Wort „User“ auftauchen muss. Mal sieht man allumfassende Change Requests als „User Story“ getarnt. Mal erkennt man darin den offensichtlichen, rein technisch motivierten Ruf eines Softwareentwicklers nach einer notwendigen Softwareanpassung, und mal ist es letztlich nur noch der Typ eines Tickets in einem „agilen Projekt- und Vorgangsnachverfolgungstool“. Kaum eine Form der Anforderungsspezifikation scheint so leichtgewichtig und einfach zu verstehen, und gleichzeitig so schwierig in die Praxis umzusetzen zu sein, wie die User Story.

Aber was macht eine User Story tatsächlich aus? Wann kann man sie guten Gewissens so nennen? Welche objektiven Kriterien kann man anlegen, und kann man „gute User Storys“ von „schlechten User Storys“ unterscheiden? Was genau sind Akzeptanzkriterien? In welchem Kontext bewegen sich User Storys überhaupt? Wer schreibt sie, wer liest sie und warum eigentlich? Fragen über Fragen, denen es am besten mit einer gesunden Mischung aus Wissen, Erfahrung und Pragmatismus zu begegnen gilt!

Bild: Scott Adams; United Features Syndicate Inc.; 01/10/2003

Um nun aber bei der User Story selbst zu bleiben, zeigt die Erfahrung, dass es in den Teams beim Thema Wissen oft schon an einer einfachen, griffigen Definition des Begriffs fehlt. Hier ein Vorschlag:

 „Eine User Story ist eine kurze, prägnante Beschreibung einer Anforderung und deren Nutzen aus der Perspektive und in der Sprache eines Users“

Damit möchte ich den Fokus lenken auf folgende Aspekte:

  • der Nutzen für den Anwender bzw. der Geschäftswert für den Kunden sollte klar erkennbar sein
  • es geht um eine abgrenzbare, fachliche Anforderung, nicht um ein vollumfängliches Anforderungspaket
  • die Anforderung sollte so einfach und prägnant formuliert sein, dass man sie zu kleinen, konkreten Aufgabenpaketen verfeinern kann
  • die Sprache sollte die Fach-/Domänensprache des Anwenders sein, und als solche für alle Beteiligten verständlich sein
  • die Perspektive sollte die des Anwenders sein

Aus guter Verständlichkeit und Abgrenzbarkeit ergeben sich zumeist auch eine deutlich bessere Bewertbarkeit und Schätzbarkeit der viel beschworenen “relativen Komplexität“ und eine bessere Planbarkeit der Anforderung im Sinne des Anwenders und des Nutzens.

Zum Wissen über User Storys gehören natürlich die bekannten und überall zu lesenden Zutaten, wie die „Story Card“ Best Practice in der Form „Als […] möchte ich […], damit […]“, oder die INVEST-Kriterien, die beim Bewerten und Objektivieren weiterhelfen. Und natürlich sollte man um das Vorgehensmodell wissen, in dem man sich bewegt, und welches kein waberndes „agiles Konstrukt ohne Namen“ sein sollte.

Zur Erfahrung gehört es, vor allem Missverständnisse und Missstände im Zusammenhang mit User Storys auszuräumen.
Es hilft bspw. verstanden zu haben, dass eine User Story immer eine Einladung zur Konversation und Kollaboration darstellen sollte, und keine möglichst früh aufzuschreibende und nicht mehr verhandelbare (An-)Forderung. Provokativ gesagt: die User Story ist letztlich erst dann vollständig beschrieben, wenn sie erfolgreich umgesetzt wurde.

Auch sollte die Beschreibung der User Story nicht mit ihren Akzeptanzkriterien verwechselt werden. Diese wiederum sollten Ausdruck der relevanten fachlichen Details und deren Verifikation und Testbarkeit dienlich sein, selbst aber nicht zu einem Mini-Fachkonzept „ausarten“, sondern besser eine hilfreiche Ausgangsbasis für automatisierte Akzeptanztests darstellen.

Nicht selten ist zu beobachten, dass der „[…], damit […]“-Teil der Beschreibung aus der Story Card Best Practice fehlt, da sich Teams schwer damit tun, diesen mit Inhalt zu füllen – auf nicht wenigen Webseiten findet man ja schließlich, dass man diesen Teil auch weglassen könne. Die Erfahrung lehrt mich, dass damit häufig kein hinreichendes Verständnis für die Fachlichkeit, keine Ursachenanalyse und keine Diskussion über Alternativen einhergehen. So entstehen unangemessene und schlimmstenfalls überflüssige Lösungen, für Probleme, über die man nicht wirklich gesprochen hat, weil niemand nach dem „Warum“ gefragt hat (oder fragen durfte). Besser erscheint es mir da, sich immer erst den Nutzen klar zu machen, und dann nach Lösungen zu suchen. Und wenn man den Nutzen schon hat, warum ihn nicht auch explizit formulieren?!

Zum Pragmatismus wiederum gehört es, möglichst keine Symptome zu bekämpfen, sondern Ursachen, und nicht alles übergenau beschreiben und reglementieren zu müssen, denn oft ist weniger mehr. Dies gilt für das Schneiden und Formulieren von User Storys genauso wie für das Arbeiten im Team. Stellen Sie sich bspw. eine Teamkonstellation mit „ausgeprägter Diskussionskultur“ zwischen Product Owner, Entwicklern und Testern vor, die sich gegenseitig „Renitenz aus Prinzip“ unterstellen. In einer solchen Situation wird man Missverständnisse in User Storys durch keine noch so präzise Formulierung von Akzeptanzkriterien oder einer „Definition of Ready“ verhindern können. Hier gilt es – auf mehreren Ebenen – eine gemeinsame Sprache zu entwickeln und Konsens zu erzielen.

Lange Rede, kurzer Sinn: wie so vieles im Leben, ist auch die User Story zur selben Zeit einfacher, als man glaubt und komplizierter, als man denkt. Aber es ist äußerst lohnenswert, sich damit auseinander zu setzen und alteingesessene Formen der Anforderungsspezifikation zu überdenken – und unerlässlich, wenn man sich ernsthaft mit Agiler Softwareentwicklung beschäftigen möchte!