Was ist eine User Story?

Wenn Du Dich auch in der IT oder in der Software-Entwicklung tummelst, sind User Stories sicher nichts unbekanntes für Dich. Das sind in Kund*innen- bzw. Nutzer*innensprache 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 für ein Reiseportal 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. Richtig angewendet, helfen User Stories zudem, die für Nutzer*innen und Kund*innen wichtigen Dinge von den unwichtigen abzugrenzen. Gleichzeitig ist das ein radikaler Paradigmenwechsel zum tradierten Requirements-Engineering, wo meist umgehend Lösungen definiert werden.

Häufig führen Unternehmen die Arbeit mit User Stories im Rahmen „agiler Transformationen“ als Werkzeug ein. Allerdings werden die User Stories dann für gewöhnlich in die bisherigen Vorgehensweisen „eingefügt“. Die User Stories werden z.B. in das vorhandene Ticket-Management System eingegeben oder in Requirements-Spezifikationen aufgeschrieben.

Requirements Management per User Story

Außer dem Namen ändert sich meist nichts an der Vorgehensweise. 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 dysfunktional. Ursache ist die blinde Anwendung eines Rezeptes ohne den darin liegenden Paradigmenwechsel zu vollziehen. User Stories werden auf das bloße Aufschreiben reduziert. Trotzdem erhofft man sich wohl, damit Verbesserungen zu erzielen.

Wer schreibt der bleibtzurück

Aus dem vorhandenen Verhaltensmuster heraus, dass Spezifikationen aufgeschrieben werden, konzentriert sich auch bei den User Stories alles auf das Schreiben. Dabei ist der Prozess des Schreibens keineswegs schlecht. Im Gegenteil, schreiben kann eine wirksame Denkunterstützung sein. Allerdings steht im Zentrum der Diskussion meist, wie User Stories in Task-Management Tools verwaltet werden. Ausgeklügelte Eingabemasken und „Workflows“ werden implementiert. Man regelt, welche Datenfelder und Aufgabenstatus zu verwenden sind, wer welche Zugriffsrechte hat und dergleichen mehr.

Auch an der in klassischen Unternehmen vorhandenen funktionalen Trennung von Abteilungen und Bereichen ändert sich meist wenig. Die Anfordernden schreiben Ihre User Stories in Tickets, die Entwickler*innen dann umsetzen sollen. Natürlich kommt schnell der Vorwurf aus der Entwicklung, dass man die User Stories so nicht umsetzen könne. Darauf reagiert dann das Requirements-Management mit noch genauer spezifizierten User Stories. Es werden Schablonen erdacht, in denen noch mehr Datenfelder auszufüllen sind, damit auch jedes Detail der Anforderung erfasst wird. Kommt Dir das bekannt vor?

Derweil hatten die Erfinder der User Stories bereits begriffen, dass der oben geschilderte Weg in eine Sackgasse führt. 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. Was steckt nun hinter diesen User Stories? Darauf will ich nachfolgend einmal mit etwas mehr Tiefe eingehen – Achtung Theorie!

Gedanken sind nicht frei

Das menschliche Gehirn als biologisches System beheimatet sozusagen unser Bewusstsein.  Das Bewusstsein besteht aus Gedanken, die wir unaufhörlich produzieren. Wir können nicht Nichts denken. Das Bewusstsein erschafft sich so quasi permanent selbst. Die chilenischen Neurobiologen Humberto Maturana und Francisco Varela haben dafür den Begriff Autopoiesis geprägt [1]. Autopoietische Systeme haben die folgenden drei wesentlichen Eigenschaften:

  • Selbstreferenzialität: Die Grundoperationen folgen unaufhörlich auf einander und beziehen sich auf sich selbst.
  • Informationelle Offenheit: Das System kann Informationen von außen aufnehmen, welche Einfluss auf die stattfindenden Operationen haben.
  • Operationelle Geschlossenheit: Die Operationen sind immer gleich und verlassen das System nicht. Im Bewusstsein folgt einem Gedanken immer ein weiterer Gedanke (nicht etwa irgendetwas anderes). Gedanken verlassen das Bewusstsein nicht.

Besonders interessant für meine Argumentation ist die operationelle Geschlossenheit. Nehmen wir an, ich bin Nutzer eines Produktes, und wünsche mir eine bestimmte Funktionalität, die dieses Produkt bieten soll. Der Wunsch ist in Form von Gedanken in meinem Bewusstsein vorhanden.

Kein Gedankenaustausch

Da meine Gedanken mein Bewusstsein nicht verlassen können, kann ich die Informationen darin, niemandem direkt übergeben. Ich muss also einen Umweg – meist über Sprache – nutzen, und meine Gedanken beschreiben.

Bei dieser Beschreibung 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 ihre Gedankenwelt. Ein weiterer Übersetzungsschritt mit Informationsverlusten. Die Verluste entstehen dadurch, dass bei den Übersetzungen jeweils unsere individuellen Weltbilder Anwendung finden. Gesprochene oder geschriebene Worte werden dementsprechend unterschiedlich interpretiert.

Die jeweiligen Gedanken verschiedener Personen zu einer User Story können durch Sprache nur unvollständig beschrieben werden.
Unsere Gedanken finden keinen Eingang in unsere Kommunikation – wir können sie nur umschreiben

Ich kann als Sender deshalb nicht beeinflussen, in welchen Gedanken meine Worte enden. Genau genommen kann die empfangende Person auch nicht behaupten, sie hätte mich verstanden. Sie kennt ja meine Gedanken nicht und kann unmöglich meine Übersetzung prüfen. Den sprichwörtlichen Gedankenaustausch gibt es also eigentlich nicht. Es gibt nur subjektive Beschreibungen von Gedanken.

Menschen kommunizieren nicht

Der Soziologe Niklas Luhmann griff denn Begriff der Autopoiesis auf, baute ihn aus und machte daraus ein Schlüsselkonzept der auf ihn zurückgehenden soziologischen Systemtheorie. Konsequent schlussfolgert er daher auch: „Der Mensch kann nicht kommunizieren […]“ [2,3]. Denn, um es mal mit meinen Worten als Techniker zu beschreiben: Wir sind unfähig, Informationen verlustfrei von Mensch zu Mensch zu übertragen. Aber es wird noch schlimmer.

Sprache ist unzulänglich

Wir müssen also den Umweg über gesprochene oder geschrieben Sprache wählen. Bei den Übersetzungsschritten gehen Informationen verloren oder werden verfälscht. Das liegt an unseren unterschiedlichen Prägungen und Weltbildern, die wir in den Übersetzungsschritten als Referenzen heranziehen.

Sage ich zum Beispiel so etwas wie „ein Smartphone muss intuitiv bedienbar sein“, dann entsteht jetzt gerade in Deinem Kopf ein Bild davon, was „intuitiv“ ist. Wenn wir Glück haben dann gleichen sich Deine und meine Gedanken vielleicht weitgehend. Sicherlich aber niemals vollständig. Selbst wenn, dann wäre dieser Glücksfall extrem selten und wir würden es womöglich nicht einmal bemerken. Sehr viel wahrscheinlicher ist, dass in Deinem Kopf eine Vorstellung von intuitiver Bedienung existiert und meinem Kopf eine davon unterschiedliche.

Und das ist so, obwohl wir in unserem Kommunikationsversuch ein- und dasselbe Wort verwendet haben. Weil Sprache stets subjektiv interpretiert wird, ist sie immer ungenau. Sprache ist nie ausreichend, um Gedanken vollkommen präzise und unmissverständlich zu beschreiben.

Um das berühmte gemeinsame Verständnis zu schaffen, müssen wir in einen Dialog gehen. 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. Klingt anstrengend? Ist es manchmal auch.

Die Anstrengung lohnt sich

Es gibt aber 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.

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

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. Mein Rat an Dich: Tappe nicht in die Falle, die soziale Dichte enger Zusammenarbeit durch (digitalisierte) überformalisierte Kommunikationskanäle ersetzen zu wollen. Die vermeintliche Abkürzung ist schnell eine Sackgasse.

Referenzen

  1. Autopoiesis: The organization of living systems, its characterization and a model. Francisco J. Varela, Humberto R. Maturana, and R. Uribe. In: Biosystems. 5, 1974, S. 187–196.
  2. Soziale Systeme. Grundriß einer allgemeinen Theorie. Niklas Luhmann. Suhrkamp, Frankfurt am Main 1984.
  3. Niklas Luhmanns Theorie sozialer Systeme. Georg Kneer, Armin Nassehi (Hrsg.). Wilhelm Fink Verlag, München 1993.

Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.