Storytelling und Agile beeinflussen sich schon seit Jahren gegenseitig. Hier ist ein praktischer Leitfaden, wie Sie diese Methode in jedem Sprint und vor jedem Publikum anwenden können, ohne dabei den Eindruck zu erwecken, Sie hätten zu viele Bücher darüber gelesen.

Du bist bereits ein Geschichtenerzähler. Du weißt es nur noch nicht

Ich bin ein großer Fan von Pub-Quizzen (ich will nicht prahlen, aber mein Team ist wirklich gut – Go Llamas!), daher hier ein kleines Quiz für euch: Was haben „Der Herr der Ringe“, ein Marvel-Film und das letzte Sprint-Planungsmeeting eures Teams gemeinsam?

Wenn Sie mit „Ein Held begibt sich auf eine Reise“ geantwortet haben – herzlichen Glückwunsch, dann betreiben Sie bereits Storytelling. Sie wissen es vielleicht nur noch nicht.

Schauen Sie sich einmal kurz Ihre tägliche Arbeit an. Sie schreiben User Stories. Sie schätzen Story Points. Sie erstellen User Journeys, entwickeln Szenarien und fassen Dinge zu Epics zusammen. Wenn Sie schließlich eine Funktion veröffentlichen, verfassen Sie Release Notes, in denen Sie den Nutzern erklären, was sie leistet und warum sie wichtig ist.

Jede einzelne dieser Aktivitäten wurde mehr oder weniger direkt aus der Kunst des guten Erzählens übernommen.

​

Und doch: Immer wenn ich das Wort storytelling im technischen Kontext erwähne, ist die häufigste Reaktion ein höflicher, aber entschiedener Blick, der zu sagen scheint: „Das ist sehr interessant, Diana, aber wir haben diese Woche eine Veröffentlichung.“

Na gut. Dann lass mich kurz meine Argumente darlegen.

Warum Storytelling funktioniert

Gutes Storytelling ist eines der am meisten unterschätzten Werkzeuge in der Softwareentwicklung – nicht nur, weil es Ihre Release-Notes ansprechender gestaltet, sondern vor allem, weil es gleich zwei Dinge verändert: Es verändert die Einstellung Ihrer Nutzer zum Produkt und es verändert die Einstellung Ihres Teams zur Entwicklung des Produkts.

Wenn es funktioniert, motiviert, fesselt und inspiriert es. Das Storytelling hat diese Gabe. Wenn es nicht funktioniert, hat man am Ende einen Backlog voller Funktionen, die eigentlich niemand wirklich wollte – entwickelt von Leuten, die einem nicht so recht erklären konnten, warum sie diese Funktionen entwickelten und wie es weitergehen sollte. Sie wollten einfach nur die Aufgaben als „erledigt“ abhaken.

Ich möchte also Folgendes verdeutlichen: Ein Produkt ist eine Geschichte, und der Nutzer ist immer der Held. Nicht du, nicht dein Produkt und nicht dein Unternehmen. Im Tech-Marketing höre ich das oft: „Unser Produkt kann [dies]“; „Unser Unternehmen hat [das] getan“; „Finanziert von [diesem Typen]“. Das interessiert niemanden. nObOdy CaReS.

Was kann man stattdessen tun? Konzentrieren Sie sich auf den Nutzer. Der Nutzer ist die Hauptfigur. Dort sollte das Rampenlicht leuchten: auf den Nutzer, nicht auf das Produkt. Alles Gute ergibt sich daraus, wenn man diese eine Besetzungsentscheidung richtig trifft.

Die nächste Frage lautet natürlich: Wie lässt sich diese Erkenntnis konkret in der täglichen Arbeit umsetzen? Lassen Sie uns das Thema daher in zwei Teile aufteilen: Wie setzt man Storytelling in agilen Prozessen ein, und wann sollte man es einsetzen?

Teil 1. Wie man Storytelling in agilen Methoden einsetzt: die sieben Cs

Die meisten klassischen Rahmenkonzepte des Storytelling sind sich über eine Handvoll Elemente einig, die wie ein 3D-Puzzle ineinanderpassen. Ich habe sie in einer Liste von Stichwörtern zusammengefasst, die alle mit dem Buchstaben C beginnen, da sie sich leicht merken lassen und sich fast perfekt auf einen agilen Arbeitsablauf übertragen lassen: Kontext, Charakter, Konflikt, Höhepunkt, Schluss, Verbindung und Komplexität.

Hier sind sie, eines nach dem anderen, jeweils mit einer Übertragung auf den Bereich der Technologieprodukte.

1. Kontext – Die Kulisse schaffen

Jede Geschichte hat ihren Anfang. Bevor du deine erzählen kannst, musst du wissen, wem du sie erzählst und warum es diese Menschen interessieren sollte.

Im Entwicklungszyklus ist dies der Teil, in dem du eine Produktgeschichte entwirfst und zwei Fragen beantwortest, bevor du auch nur eine einzige Zeile Code schreibst: Für wen entwickle ich dieses Produkt? Und warum sollten diese Menschen ihm Beachtung schenken? Wenn du diese Fragen nicht beantworten kannst, wird dir kein noch so cleverer Code und keine noch so schöne Benutzeroberfläche helfen. Du wirst eine großartige Geschichte in einem leeren Theater erzählen.

2. Figur – Lerne deinen Helden kennen

In jeder Geschichte, die es wert ist, gelesen zu werden, gibt es eine Hauptfigur, die uns am Herzen liegt. Bei Ihrem Produkt ist diese Figur Ihre Nutzerpersönlichkeit. Hier ist ein Beispiel für eine Nutzerpersönlichkeit aus einem Softwareprodukt für Projektmanager:

Eine Persona ist jedoch mehr als nur ein Name und ein Stockfoto oben auf einer Confluence-Seite; sie ist eine Methode, sich selbst dazu zu zwingen, immer wieder nach dem „Warum“ zu fragen. Warum braucht diese Person mein Produkt? Warum ist gerade diese Funktion für sie wichtig? Welche Motivation steckt hinter der Anfrage?

Hinter jeder Persona steckt ein echter Mensch mit Frustrationen, Motivationen und Gründen dafür, auf das, was Sie gerade entwickelt haben, zu klicken (oder nicht zu klicken). Seien Sie neugierig und sammeln Sie Daten über diese Person. Sobald Sie das tun, wird Ihre Roadmap mehr Sinn ergeben.

3. Konflikt – das zu lösende Problem

Ohne Konflikt gibt es keine Geschichte. Niemand möchte einen Roman lesen, in dem eine Figur aufwacht, einen perfekten Tag verbringt und dann wieder einschläft. Das Gleiche gilt für Produkte: Wenn es kein Problem zu lösen gibt, gibt es keinen Grund, das Produkt auf den Markt zu bringen.

An dieser Stelle definieren Sie das Problem des Nutzers. Was will Ihr Nutzer? Warum will er es? Was ist sein Problem? Formulieren Sie dies klar und deutlich in verständlicher Sprache, bevor Sie mit der Entwicklung der Lösung beginnen.

Denn „die Geschäftsleitung möchte hier einen Button“ und „die Nutzer verlieren jeden Montagmorgen zwanzig Minuten und ihre ganze Geduld bei der Suche nach ihren wöchentlichen Aufgaben“ sind zwei völlig unterschiedliche Vorgaben, und eine davon wird zu einem viel besseren Produkt führen als die andere.

4. Höhepunkt [oder steigende Spannung] – die User Story

Nun kommen wir zu dem Teil der Geschichte, an dem die Handlung in Gang kommt. In der agilen Entwicklung ist dies die User Story – und wenn man genauer hinschaut, ist sie ein wunderbares kleines erzählerisches Mittel. Der Name sagt schon alles: „User. Story“.

Das klassische Format lautet „Persona + Bedarf + Zweck“: Als [Benutzer] möchte ich [etwas], damit [Ergebnis]. Drei kleine Bestandteile, die dem Team jedoch gemeinsam drei wichtige Dinge auf einmal vermitteln: Was wir entwickeln, warum wir es entwickeln und welchen Mehrwert es schafft. Es ist eine vollständige Kurzgeschichte in einem einzigen Satz.

Hier ist ein Beispiel aus dem Backlog eines Softwareprodukts, das Projektzeitpläne erstellt:

Kurz gesagt: Das Team weiß, für wen es die Lösung entwickelt (Patrick, den vielbeschäftigten Projektmanager), was er braucht (Farbkontrolle) und warum das wichtig ist (persönlicher Stil, Präsentationsqualität, Markenkonsistenz). Plötzlich ist „Farben anpassen“ nicht mehr nur eine Zeile in einem Jira-Ticket, sondern ein kleiner Erfolg in Patricks Arbeitsalltag.

5. Fazit – die Demo

Jede Geschichte hat einen Moment, in dem sich die Spannung endlich löst. In der Softwareentwicklung ist das Ihre Demo.

Die goldene Regel lautet hier genauso wie die, auf die gute Romanautoren schwören: Zeigen, nicht erzählen. Lesen Sie nicht einfach nur eine Liste mit Funktionen vor. Gehen Sie nicht einfach nur die Spezifikationen durch. Zeigen Sie stattdessen die Auswirkungen auf. Zeigen Sie, was sich für den Nutzer ändert. Zeigen Sie, wie sein Alltag dadurch besser, schneller und stressfreier wird. Zeigen Sie, wie Sie das Problem gelöst haben, das Sie in Schritt drei angegangen sind.

Eine umfassende Demo sollte stets die Nutzerreise vom Problem bis zur Lösung veranschaulichen und nicht einfach nur die Lösung dem Publikum präsentieren, in der Hoffnung, dass dieses durch Rückentwicklung selbst herausfindet, welches Problem damit gelöst werden sollte.

Hier ist ein Beispiel für eine Journey Map für den Nutzer eines Softwareprodukts:

6. Verbundenheit – der emotionale Gewinn

Ich weiß, dass man in der IT-Branche nicht oft über Gefühle spricht, und dass dies ein Aspekt ist, den die meisten Produktteams beiseite schieben. Aber die besten Geschichten informieren nicht nur, sie wecken auch Emotionen. Das sollte auch Ihr Produkt tun.

Hier kommt ein Tool wie die Empathiekarte ins Spiel. Was kann Ihr Produkt tatsächlich für jede Ihrer Nutzer-Personas leisten? Und was noch wichtiger ist: Wie werden sich die Nutzer dabei fühlen? Weniger gestresst? Selbstbewusster? Wie ein Zauberer, der in nur drei Minuten einen wunderschön formatierten Projektzeitplan erstellen kann?

Dieses Gefühl ist Ihr Wertversprechen. Die Funktionen sind lediglich der Mechanismus, durch den es vermittelt wird.

7. Komplexität – Geschichten, Epen und die große Suche

Keine gute Geschichte besteht nur aus einer einzigen Szene. Es gibt einen Handlungsbogen, einen Aufbau, ein Gesamtbild. Das Gleiche gilt auch für Agile.

Eine Story beschreibt den Handlungsbogen einer einzelnen abgeschlossenen Aufgabe. Ein Epic zoomt weiter heraus und zeigt das übergeordnete Ziel, das viele Stories miteinander verbindet. Ein Thema zoomt noch weiter heraus. Richtig aufeinander abgestimmt beschreiben sie mehr als nur ein langweiliges Backlog; sie beschreiben die übergeordnete Mission eures Produkts. Die große Geschichte. Das, was ihr hier wirklich erreichen wollt.

Wenn euer Team erkennen kann, wie ein kleines Ticket über einen Farbwähler in die übergeordnete Aufgabe „Projektmanagern helfen, klar mit ihren Stakeholdern zu kommunizieren“ passt, ist es motivierter, besseren Code zu schreiben. Es schreibt Code, der irgendwo hingehört.

Teil 2. Wann man Storytelling einsetzen sollte: Man muss wissen, wer zuhört

Zu wissen, wie eine gute Geschichte aufgebaut ist, ist nur die halbe Miete. Die andere Hälfte besteht darin, zu wissen, wem man sie erzählt. In einem typischen Produktzyklus richtet man sich eigentlich an drei Zielgruppen, und jede davon benötigt eine etwas andere Version derselben Geschichte.

Führungskräfte

Wenn Sie Ihre Fortschritte präsentieren, widerstehen Sie der Versuchung, eine Folie mit Funktionen, Strategien und technischen Daten vorzuführen. Führungskräfte begeistern sich nicht für Aufzählungspunkte. Sie begeistern sich für Veränderungen. Für Geschichten.

Wie wird Ihr Produkt das Leben anderer Menschen verändern – persönlich, beruflich, finanziell? Was wird in der Welt anders sein, wenn diese Funktion eingeführt wird? Beginnen Sie damit, dann kommen die Details der Roadmap viel besser an. Emotionen treiben das Handeln an, besonders in den Vorstandsetagen.

Ihr internes Team

Das ist die Zielgruppe, an die ich am meisten denke, und das ist auch der Grund, warum ich mich dafür eingesetzt habe, eine Einheit zum Thema „Produktgeschichte“ in die Einarbeitung neuer Mitarbeiter aufzunehmen. Auch Ihr internes Team braucht eine Geschichte – zwar nicht dieselbe, die Ihre Nutzer zu hören bekommen, aber dennoch eine Geschichte.

Warum sollte ihnen dieses Produkt am Herzen liegen? Warum sollten sie ihre Zeit, ihre Aufmerksamkeit und – seien wir ehrlich – ihre geistigen Fähigkeiten in die Entwicklung genau dieser Funktion investieren, anstatt in eine der vielen anderen Aufgaben, die sie erledigen könnten?

Sprints funktionieren besser, wenn die Beteiligten das Gefühl haben, an etwas zu arbeiten und nicht nur etwas hinter sich zu bringen. Die Entwicklung eines Produkts sollte mehr sein als nur ein Job. Durch Storytelling macht man daraus mehr, verleiht ihrer Arbeit einen Sinn.

Ihre Nutzer

Und schließlich: die Menschen, für die Sie das alles eigentlich tun. Wenn Sie mit Ihren Nutzern kommunizieren – auf Ihrer Website, im Onboarding-Prozess, in Ihren E-Mails, in Ihren Support-Dokumenten –, sollten Sie stets diese vier Elemente im Hinterkopf behalten:

• Wer ist der Held? Immer der Nutzer. Nicht Sie. Nicht Ihr Produkt. Nicht Ihr Unternehmen.
• Wer ist der Bösewicht? Alles, was Ihre Nutzer daran hindert, ihre Ziele zu erreichen. Vielleicht ist es ein klobiges, veraltetes Tool, vielleicht ist es verschwendete Zeit, vielleicht ist es ein Vorgesetzter, der auf einen Bericht wartet.
• Was ist das Ziel? Das, was Ihr Nutzer tatsächlich braucht – in seinen Worten, nicht in Ihren.
• Wer ist der Wegweiser? Ihr Produkt. Der weise Mentor, der dem Helden hilft, dorthin zu gelangen, wo er hinwill.

Wenn Sie diese vier Punkte richtig umsetzen, werden Sie feststellen, dass sich die Geschichte fast von selbst schreibt. Wenn Sie sie falsch umsetzen, klingen Sie am Ende wie jedes andere SaaS-Unternehmen im Internet: wie ein Held auf verzweifelter Suche nach einem Publikum, der darum kämpft (und dabei scheitert), auch nur einen Funken Aufmerksamkeit zu erlangen.

Noch eine Sache

Wenn es einen einzigen Satz gibt, den ihr aus all dem mitnehmen solltet, dann ist es der, mit dem ich begonnen habe: Ein Produkt ist eine Geschichte, und der Nutzer ist der Held. Alles andere – die Personas, die User Stories, die Demos, die Empathiekarten – ist lediglich Handwerk im Dienste dieser einen Idee.

Gutes Storytelling schreibt dir keinen Code. Es führt keine Sprints durch. Es bringt dein Release nicht an einem Donnerstag auf den Markt (und nein, wir veröffentlichen keine Releases freitags!). Aber es sorgt dafür, dass sich alle ein bisschen mehr in dein Produkt verlieben: dein Team, deine Stakeholder und – wenn du es richtig machst – deine Nutzer.

Und ganz ehrlich, meine Liebe, das ist genau die Art von Geschichte, die dir wirklich am Herzen liegt.