Ein weiterer agiler Unsinn in meinen Augen ist das weit verbreitete User-Story-Schema. In Schulungen sage ich immer, dass ca. 90% aller Scrum-Teams da draußen glauben, dass man mit Scrum auch User Storys machen muss, kommen allerdings dabei niemals über die „Stützräder-Phase“ von User Storys hinaus. Zeit, damit einmal ein wenig aufzuräumen.

Ein Blick in die Entstehungsgeschichte

Vorab ein paar Fakten zu User Storys. Im Scrum-Guide tauchen User Storys lediglich als Beispiele für Product Backlog Einträge auf. Man kann sein Product Backlog auch mit jeder anderen hilfreichen Form beschreiben.

Tatsächlich wurden User Storys von einer anderen agilen Methode als Scrum geprägt, nämlich dem eXtreme Programming (XP). Um User Storys und den agilen Unsinn in den meisten Scrum-Teams besser zu verstehen, hilft vielleicht ein kleiner historischer Ausflug zu User Storys und woher sie kommen.

Das erste XP-Team sollte damals bei der Firma Chrysler eine neue Zeitaufschreibung entwickeln. Chrysler war zu dem Zeitpunkt bekannt dafür, dass sie allerlei Projekte beginnen, ihnen aber irgendwann das Geld ausgeht und sie dann weniger wichtige Projekte schnell wieder einstellen. Das erste XP-Team hat diesen Umstand als Herausforderung angenommen und mit allen Elementen in XP versucht, jede Woche etwas Auslieferfähiges und Einsetzbares vorzuweisen, damit man am Ende des Geldes halt nicht das Projekt als Mißerfolg abschreiben muss.

Die Entwickler saßen vor Ort bei der Firma Chrysler und wußten eingangs nicht so wirklich, was sie jetzt genau in die neue, tolle Zeitaufschreibung für die MitarbeiterInnen bei der Firma Chrysler einbauen sollten. Deshalb sind sie losgezogen und haben potentielle Anwender (User) bei der Firma Chrysler befragt. „Wir bauen ja gerade eine neue Zeitaufschreibung. Stell‘ Dir vor, das wäre das perfekte System, mit dem Du Deine Arbeitszeiten zurückmelden könntest. Wie würdest Du das einsetzen?“ Basierend auf diesen Fragen haben die potentiellen Anwender dann damit begonnen, Geschichten (Storys) über diese hypothetische System zu erzählen. Die EntwicklerInnen haben aufmerksam zugehört und sich bei allem, was für sie umsetzbar erschien, Stichworte auf Karteikarten vermerkt. Am Ende ihrer Interviews hatten sie dann einen Stapel an Karteikarten, mit dem sie den Fortschritt im Projekt tracken konnten.

Weil potentielle User Geschichten erzählen, prägten die XP-Entwickler den Begriff User Story. Schaut man sich heute bei den 90% der Scrum-Teams um, die meinen User Storys einzusetzen, dann sind diese häufig ohne viele Geschichten durch User entstanden.

Das berühmte User Story Template

Der allererste XP-Coach war Ron Jeffries. Auf ihn geht das heute weit verbreitete Satz-Template bezüglich User Storys zurück:

Als <User/Persona/Rolle>
möchte ich <Funktion>,
damit <Mehrwert>.

Diese Satz-Schema hat sich dermaßen bei vielen Scrum-Teams eingeprägt, so dass sie beispielsweise in ihrem Product Backlog Management Tool eingestellt haben, dass eine neue User Story im Product Backlog diesem Satzschema genügen muss oder halt vom Tool abgelehnt werden soll. Wenn man zurück auf die Historie blickt, merkt man schnell, dass das vollkommener Blödsinn sein muss, denn die Erfinder von User Storys haben tatsächlich einfach Stichwörter verwendet. Das Satzschema ist erst viel später entstanden.

Dieser Unsinn geht so weit, dass es eine zeitlang Twitter-Accounts gab, die die schlimmsten User Storys in die große, weite Welt hinausposaunt haben. Mein Liebling darunter ist immer noch der folgende:

Als Codezeile
möchte ich eine zweite Codezeile,
damit ich nicht mehr so alleine bin.

Das Tool ist zufrieden, die Metrik sieht toll aus, aber haben wir damit etwas sinnvolles erreicht? Ich bezweifle es doch sehr stark.

Vor einigen Jahren habe ich eine Session auf der Agile-Konferenz in den USA mit Ron Jeffries besucht. Damals meinte er, dass das Satzschema von ihm eigentlich so gedacht war wie Stützräder beim Fahrradfahren: am Anfang sind sie hilfreich, um die richtige Haltung bewusster einzunehmen, aber irgendwann sollte ich meine Stützräder auch abmontieren können.

Tatsächlich hat sich Ron Jeffries damals auf der Agile 2016 erst bei den Teilnehmenden für das Satzschema entschuldigt, kurze Zeit später hat er die gleiche Entschuldigung noch mal in einen Tweet gepackt und sich damit öffentlich für das Template entschuldigt, weil er selbst gesehen hat, wie sehr einige Firmen diese Stützräder mißbrauchen. Geschichten werden häufiger erzählt als geschrieben.

Die Essenz von User Storys beschreibt Ron Jeffries in einem uralten Blogeintrag von 2001 mit den drei C-Kriterien: Card, Conversation und Confirmation. Einige Zeit später hat er noch mal auf dieses abstrakte Konzept zurückgeblickt. Die Essenz ist: Eine User Story sollte auf eine physikalisch eingeschränkte Karte (Card) beschreibbar sein, z.B. einer Karteikarte oder einem A5-Post-It. Zu einer User Story gehören Akzeptanzkriterien (Confirmation). 80% des Mehrwertes durch User Storys kommt aus der Geschichte im Gespräch mit dem Benutzer (Conversation). Leider liegt der Fokus bei User Storys viel zu oft auf der Card und der Confirmation, statt den Hauptvorteil der Konversation nutzbar zu machen.

Zu den Vorteilen von dem Satz-Template maße ich mir nicht an, das auch nur annähernd so gut, wie Mike Cohn beschreiben zu können. Deswegen sei für die Vorteile von dem Satz-Schema an dieser Stelle trotzdem auf seinen sehr detaillierten Blogeintrag sowie auf sein Standard-Werk User Stories Applied verwiesen. Nur treiben Sie es nicht zu weit und vor allem nicht zu dogmatisch. Die Scrum-Polizei kommt nicht vorbei, nur weil eine Product-Backlog-Eintrag nicht dem User-Story-Schema genügt.