User Stories: Wenn keiner drüber sprechen mag

User Stories sind in Kunden- bzw. Nutzersprache geschriebene Wünsche, die ein Produkt erfüllen soll. Sie sind ein Werkzeug zum Anforderungsmanagement in der Produktentwicklung. Ursprünglich stammen User Story aus dem Extreme Programming (XP), einer iterativen Vorgehensweise zur Software-Entwicklung.  Weil starker Fokus daraufgelegt wird, zunächst das Kundenproblem zu verstehen, bevor man über Lösungen diskutiert, wird Raum für Innovation geschaffen. Richtig angewendet, fördern User Stories das Problemverständnis und helfen, die (für den Kundennutzen) wichtigen Dinge von den unwichtigen abzugrenzen.

Als wäre es eine Selbstverständlichkeit, führen Unternehmen heutzutage gerne im Rahmen „agiler Transitionen“ die Arbeit mit User Stories ein. Gerne beginnt man mit einer Scrum Einführung – weil das ja alle machen. Selbstverständlich muss man dann auch mit User Stories arbeiten – weil das irgendwie alle sagen. Vollkommener Nonsens, aber das ist Stoff für einen anderen Blogbeitrag.

Nicht falsch verstehen, ich halte User Stories für ein hervorragendes Werkzeug, sofern sie im richtigen Kontext eigesetzt werden.  In diesem Blogbeitrag geht es mir darum, dass mit User Stories wieder einmal blind ein Rezept Anwendung findet, ohne darüber zu reflektieren, wie es passgenau anzuwenden ist. User Stories werden all zu oft einfach in das bisher bekannte Requirements Management „eingefügt“. Außer dem Namen wird nichts an der Vorgehensweise geändert.

Es fallen Sätze wie „unsere Stories sind schlecht geschrieben“ oder „wir müssen Stories endlich so schreiben, dass man sie versteht“. Passend dazu findet man auch in der agilen Szene Artikel und Webinare mit Titeln wie „How to write better User Stories“.

Gemeinsame Dokumentation ≠ Gemeinsames Verständnis

Fällt Ihnen an den Sätzen oben etwas auf? Die Sätze, die ich beispielhaft herausgegriffen habe, beziehen sich auf das Schreiben von User Stories. Meist geht es auch sehr schnell um Tools wie JIRA*. Ausgeklügelte Eingabemasken und Regelwerke werden erstellt, welche Datenfelder und Aufgabenstatus zu verwenden sind und wie der digitale Workflow zu gestalten ist, und so weiter. Es steht im Vordergrund, wie User Stories aufgeschrieben und verwaltet werden.

Die „Anforderer“ schreiben Ihre User Stories in Tickets, die die „Entwickler“ dann umsetzen sollen. Das altbekannte „ich werfe Dir etwas über den Zaun“-Spiel ist unverändert da. Auf den Vorwurf der „Entwickler“, dass man die User Stories so nicht umsetzen könne, folgt meistens die Reaktion, dass die User Stories noch „genauer“ aufgeschrieben werden, was die Sache noch verschlimmert. Es werden Story-Schablonen erdacht, in denen noch mehr Datenfelder auszufüllen sind, damit auch jedes Detail der Anforderung erfasst wird.

Derweil ging es den Erfindern der User Stories um etwas ganz anderes. Es ging darum, die Kunden möglichst gut zu verstehen und darum, dass Experten verschiedener Domänen ein gemeinsames Verständnis entwickeln, was zu liefern ist und welche Kundenprobleme das löst.  Warum man durch Aufschreiben und „wegdigitalisieren“ kein gemeinsames Verständnis schaffen kann, will ich nachfolgend erklären.

Das Bewusstsein als selbstreferenzielles System

Das menschliche Gehirn als biologisches System beheimatet sozusagen unser Bewusstsein.  Das Bewusstsein besteht aus Gedanken, die unaufhörlich produziert werden. Man kann nicht Nichts denken. Dadurch erhält sich das Bewusstsein permanent selbst. Würden wir aufhören zu denken, würde das Bewusstsein verschwinden.  Man spricht auch von einem autopoietischen System. Autopoietische Systeme haben die folgenden drei wesentlichen Eigenschaften:

  • Selbstreferenzialität: Die Operationen beziehen sich auf sich selbst. Im Bewusstsein bezieht sich zum Beispiel jeder Gedanke auf den vorhergehenden.
  • Informationelle Offenheit: Das System kann Informationen von außen aufnehmen, was Einfluss auf die stattfindenden Operationen haben kann. Unsere Gedanken verändern sich also, wenn wir „Input“ bekommen.
  • 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) und 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 mir vorhanden.

Gedankenaustausch – eine Illusion

Leider kann ich meine Gedanken niemandem direkt übergeben, damit dieser Jemand genau verstehen kann, was ich von dem Produkt erwarte. Ich muss einen Umweg wählen, um meine Gedanken zu beschreiben. Für gewöhnlich benutzen wir Sprache, um unsere Gedanken zu beschreiben. Wir führen also ein Gespräch oder schreiben etwas auf.

Unsere Gedanken finden keinen Eingang in unsere Kommunikation – wir können sie nur umschreiben

Das bedeutet, dass hier schon einmal eine Übersetzung unserer Gedanken in Sprache stattfinden muss. Bei dieser Übersetzung findet mein individuelles Weltbild Anwendung. Was in meinem Kopf als präzises Bild existiert, beschreibe ich mit Hilfe meiner Sprache. Mein Gegenüber interpretiert meine Worte gemäß seinem Weltbild und seiner individuellen Sprache. Er oder sie produziert daraus seine Gedanken. Es findet also eine weitere Übersetzung statt. Beide Übersetzungsschritte sind verlust- und fehlerbehaftet. Ich kann nicht beeinflussen, in welchen Gedanken meine Worte enden, wenn ich sie aufschreibe oder ausspreche. Ich kann also keine Gedanken austauschen, sondern nur subjektive Beschreibungen von Gedanken.

Sprache ist unzulänglich

Sage ich zum Beispiel so etwas wie „die Funktion muss intuitiv bedienbar sein“, dann entsteht jetzt gerade in Ihrem Kopf ein Bild davon, was „intuitiv“ ist. Vielleicht haben wir Glück und Ihre Gedanken dazu gleichen meinen Gedanken. Wahrscheinlicher ist allerdings, dass in Ihrem Kopf jetzt Ihre Interpretation von intuitiver Bedienung existiert und meinem Kopf meine, davon verschiedene Interpretation.

Wir haben in unserer Kommunikation dasselbe Wort verwendet und dennoch ein unterschiedliches Verständnis dessen, was wir meinen. Sprache muss stets interpretiert werden und ist deshalb unzulänglich, um Gedanken vollkommen präzise und unmissverständlich zu beschreiben. Insbesondere wenn es um Emotionen geht, stellt man sehr schnell fest, dass es unmöglich ist, etwas genau in Worte zu fassen.

Ein gemeinsames Verständnis zu schaffen bedeutet, einen möglichst guten Abgleich zwischen den Gedanken der Beteiligten herzustellen. Das ist über den Umweg Sprache nur erfolgreich möglich, indem sich die Beteiligten stets durch gegenseitiges rückfragen und rückversichern wiederholt beschreiben, welche Gedanken sie zu dem Gesagten produzieren. In einer Art iterativem Prozess wird also versucht, eine gemeinsame Sprache zu entwickeln, in der die jeweiligen Interpretationen möglichst wenig voneinander abweichen.

Das klingt anstrengend?  Ist es manchmal auch. Es gibt aber schlichtweg keinen besseren Weg, ein gemeinsames Verständnis zu schaffen. Das wussten auch die Verfasser des Agilen Manifests als sie das Prinzip aufschrieben: „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“

Mein Rat an Sie ist: Tappen Sie nicht in die Falle der vermeintlichen Abkürzung, eine Diskussion durch Dokumentation zu ersetzen. Es ist keine Abkürzung sondern eine Sackgasse.

* Setzen sie für ‘JIRA’ ihr bevorzugtes Aufgabenmanagement-System ein. Ich habe beispielhaft JIRA gewählt, weil es ein sehr verbreitetes Tool ist. Ich stehe mit dem Hersteller in keinerlei Geschäftsverhältnis und ziehe keine Vorteile aus der Erwähnung 🙂

Schreibe einen Kommentar

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.