Was ist eine User Story?
Für diejenigen, die sich auch in der IT oder in der Software-Entwicklung tummeln, sind User Stories sicher nichts unbekanntes. Das sind in Nutzersprache geschriebene Wünsche, die ein Produkt erfüllen soll. Eine User Story beschreibt in möglichst kurzer und präziser Prosa ein zu lösendes Kundenproblem.
Als urlaubsreifer Familienvater möchte ich familientaugliche Pauschalreiseangebote auf der Webseite nach Region und Preis übersichtlich filtern können, damit ich für mich relevante Angebote schnell finden kann.
So könnte eine User Story in der Entwicklung eines Reisebuchungsportals aussehen
Das Konzept der User Story stammt aus dem Extreme Programming (XP), einer iterativen Vorgehensweise zur Software-Produktentwicklung. Starker Fokus liegt auf dem Verstehen des Kundenproblems. Die Lösungsdiskussion wird so lange verzögert, bis das eigentliche Problem gut genug verstanden ist. Das schafft Raum für Innovationen und smarte Lösungen. Denn oft wird im Dialog zwischen Nutzer*innen und Entwickler*innen erst klar, was der Kern des Problems ist und wie eine Lösung maximalen Kundennutzen erzeugen kann. Richtig angewendet, hilft eine User Story, die für wichtigen Dinge von den weniger wichtigen abzugrenzen. Lösungen können so schlanker werden und schneller umgesetzt werden.
Requirements Engineering per User Story
Natürlich wird man beim Anblick einer User Story, wie sie oben exemplarisch dargestellt ist, sofort einwenden, dass damit kein Software-Entwickler eine passende Lösung implementieren kann. Ist die Formulierung doch viel zu interpretationsfähig und lückenhaft. Was bedeutet beispielsweise „familientauglich” und was sind „relevante” Angebote? Eine Kernfrage ist also, wie man mit solch schwammigen Formulierungen bessere Lösungen entwickeln soll.
An dieser müssen wir mit ein paar Mythen aufräumen und einige Dinge klar stellen. Dazu soll dieser Artikel dienen. Denn allzu oft führen Unternehmen User Stories ein, ändern aber nichts an der bisherigen Vorgehensweise. Damit lässt sich der Nutzen des Formats User Story aber kaum heben. Im Gegenteil, oft kehrt nach kurzer Zeit Frust ein und Kritik wird laut: „unsere Stories sind schlecht geschrieben“ oder „wir müssen Stories endlich so schreiben, dass man sie versteht“. Das eigentlich hervorragende Werkzeug wird so schnell dysfunktional.
Die Einführung von User Stories muss mit einem Paradigmenwechsel einhergehen. Das Verbesserungspotenzial liegt nämlich in der Art und Weise, wie mit User Stories gearbeitet wird. Sie bedeutet eine Abkehr vom Glauben, dass geteilte Dokumentation mit geteiltem Verständnis gleichzusetzen ist. Eine User Story ist zunächst einmal eine Einladung zum Gespräch. Im damit startenden Dialog zwischen Nutzer*innen und Expert*innen wird dann Verständnis geschaffen.
Die drei C’s
Ron Jeffries hat 2001 formuliert, dass eine User Story aus den drei folgenden Teilen besteht – den sogenannten drei C’s:
- Card: Eine schriftliche Darstellung der Story, die als Gedankenstütze bei der Arbeit dient.
- Conversation: Ein Dialog zwischen Expert*innen und Nutzer*n, der dazu dient, alle relevanten Details der User Story zu klären.
- Confirmation: Tests bzw. Testkriterien, die die Details definieren, wann die User Story abgeschlossen ist.
Dabei sollte Conversation den wesentlichen Teil, etwa 80% der insgesamt aufgewendeten Zeit in Anspruch nehmen. Das macht deutlich, wo der Paradigmenwechsel stattfindet. Ich kenne nur wenige Unternehmen, die das konsequent beherzigen. Meist wird argumentiert, dass man keine Zeit habe, und dass man User Stories eben „genau genug aufschreiben müsse“, damit man keine Zeit mit Diskussionen verschwende.
Wer schreibt, der bleibt … zurück
Weil man sich dann wieder auf das möglichst genaue Aufschreiben – man könnte auch Spezifizieren sagen – konzentriert, fällt man schnell wieder in das bisherige Verhaltensmuster zurück. Das passt auch besser dazu, dass in vielen Unternehmen Business Analysten und Requirements-Ingenieure in Abteilungen getrennt von Entwicklern und Testern arbeiten. Anstatt miteinander in den Dialog zu gehen und interdisziplinär zu arbeiten, werden User Stories aufgeschrieben und zur Implementierung übergeben.
Häufig werden dabei User Stories in Task-Management Tools verwaltet. Wenn bei der Übergabe immer mehr Probleme entstehen, werden dann ausgeklügelte Eingabemasken und „Workflows“ implementiert. Qualitätskriterien und Gates werden definiert, damit möglichst nichts mehr schief gehen kann. Man regelt, welche Datenfelder und Aufgabenstatus zu verwenden sind, wer welche Zugriffsrechte hat und dergleichen mehr.
Derweil übersieht man die Ursache der Probleme, die auch die Erfinder der User Stories bereits begriffen hatten: Gegenseitiges Verstehen ist durch Aufschreiben kaum zu erreichen. Interdisziplinäre Zusammenarbeit entsteht nicht durch das „über den Zaun werfen“ von Dokumenten. Geteilte Dokumentation ist eben nicht geteiltes Verständnis. Der Soziologe Niklas Luhmann brachte das in seiner prägnanten Aussage auf den Punkt: „Menschen kommunizieren nicht“.
Menschen kommunizieren nicht
Luhmann verwendet Sprache sehr präzise und bezieht sich mit seiner Aussage auf unsere Unfähigkeit, Informationen verlustfrei von Mensch zu Mensch zu übertragen [1,2]. Ohne hier zu theoretisch werden zu wollen, möchte kurz darauf eingehen.
Wenn wir über unsere Wünsche und Bedürfnisse nachdenken, dann geschieht das in Form von Gedanken, die wir produzieren. Für uns selbst entsteht meist ein sehr präzises Bild dessen, was wir möchten. Jedoch können diese Gedanken unser Gehirn nicht verlassen. Wir können sie niemandem verlustfrei mitteilen. Sprich, wir können nicht machen, dass eine andere Person die selben Gedanken und damit das selbe Bild unseres Wunsches im Kopf hat.
Um mitzuteilen was wir wollen, müssen wir also stets einen Umweg – meist über Sprache – wählen, um unsere Gedanken zu beschreiben. Dabei findet bereits ein verlustbehafteter Übersetzungsschritt statt. Was in meinem Kopf als präzises Bild existiert, beschreibe ich mit Hilfe meiner Sprache. Eine zuhörende Person hört oder liest meine Worte und interpretiert sie in ihrer Gedankenwelt. Ein weiterer Übersetzungsschritt mit Informationsveränderungen und -verlusten . Die Veränderungen in der Information entstehen dadurch, dass bei den Übersetzungen jeweils unsere individuellen Weltbilder Anwendung finden. Gesprochene oder geschriebene Worte werden dementsprechend unterschiedlich interpretiert.
Nehmen wir das obige Beispiel: Was „familientauglich” für mich bedeutet, kann sich sehr davon unterscheiden, was es für jemand anderen heißt. Je nachdem, in welcher familiären Situation wir uns befinden und was unsere jeweiligen Bedürfnisse sind. Was eben für uns „taugt”. Ich kann als Sender deshalb nicht beeinflussen, in welchen Gedanken meine Worte enden. Auch die empfangende Person kann nicht behaupten, sie hätte mich verstanden. Sie kennt ja meine Gedanken nicht. Den sprichwörtlichen Gedankenaustausch gibt es also eigentlich nicht. Es gibt nur subjektive Beschreibungen von Gedanken.
Dialog als iterative Herstellung von Verstehen
Weil Sprache stets subjektiv interpretiert wird, ist sie immer ungenau. Es kann also kaum funktionieren, Gedanken einmal aufzuschreiben, das resultierende Schriftstück zu übergeben, und dann damit genau die ursprünglich gewünschte Lösung zu entwickeln. Insbesondere wenn es um nicht-triviale Fragestellungen geht und die Informationen über mehrere Stationen ausgetauscht werden.
Um das berühmte gemeinsame Verständnis zu schaffen, gibt es nur den Weg des gemeinsamen, direkten Gesprächs. Das wussten die Erfinder der User Stories genauso wie auch die Verfasser des Manifest für Agile Software-Entwicklung. Letztere hielten ihre Erkenntnis im sechsten der zwölf Prinzipien fest:
Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
https://agilemanifesto.org/principles.html
Im Dialog können wir iterativ eine Art Abgleich zwischen unseren Gedankenbeschreibungen herstellen. Dazu gehört gegenseitiges Rückfragen und Rückversichern: „wenn Du […] sagst, meinst Du damit, dass […]?“. So tasten wir uns heran und gleichen die Interpretationen unserer Sprache einander an. Das klingt anstrengend und intensiv? Ist es manchmal auch. Es ist aber auch äußerst wirkungsvoll.
Der Anstrengung Lohn
Es gibt schlichtweg keinen besseren Weg, ein gemeinsames Verständnis zu schaffen. Und genau darum geht es bei der Arbeit mit User Stories. Erst wenn ich ein Problem in seiner Tiefe verstanden habe, kann ich gute Lösungen entwickeln. Investiere also die Zeit, die es braucht um Verständnis entstehen zu lassen und lasse Fach-Expert*innen mit Technik-Expert*innen direkt zusammenarbeiten. Idealerweise gehen sie so oft wir möglich mit den Kunden und Nutzern direkt in den Austausch. Das gilt übrigens nicht nur für die Arbeit mit User Stories, sondern überall dort wo es Menschen gemeinsam mit komplexen Sachverhalten zu tun haben.
Über die Zeit entsteht so eine gemeinsame Sprache und die benötigte Zeit für die Conversation verringert sich. Man beginnt, sich „blind“ zu verstehen. Der positive Effekt von interdisziplinärer Arbeit in stabilen Konstellationen. So werden Entwickler*innen mit der Zeit auch ein besseres Kundenverständnis entwickeln und bessere Lösungen produzieren können. Das ist gelebte Kundenorientierung.
Mein Rat also: Tappe nicht in die Falle, die soziale Dichte enger Zusammenarbeit durch (digitalisierte) überformalisierte Kommunikationskanäle ersetzen zu wollen. Die vermeintliche Abkürzung erweist sich schnell als teure Sackgasse.
Für diejenigen, die tiefer in die Thematik eintauchen wollen, empfehle ich die Bücher „User Stories Applied“ von Mike Cohn [3] und „User Story Mapping“ von Jeff Patton [4]
Referenzen
- „Soziale Systeme. Grundriß einer allgemeinen Theorie.“, Niklas Luhmann, Suhrkamp, Frankfurt am Main 1984. ISBN: 978-3518282663.
- „Niklas Luhmanns Theorie sozialer Systeme. Eine Einführung.“, Georg Kneer, Armin Nassehi (Hrsg.), Wilhelm Fink Verlag, München 1993. ISBN: 978-3825217518.
- „User Stories Applied – For Agile Software Development“, Mike Cohn, Addison-Wesley Professional, 2004. ISBN: 978-0321205681.
- „User Story Mapping: Discover the Whole Story, Build the Right Product.“, Jeff Patton, O’Reilly, 2015. ISBN: 978-3-95875-067-8.
Dieser Artikel wurde am 29. April 2019 initial veröffentlicht und am 12. Dezember 2024 überarbeitet.
