Let’s tell the User Story! mit Michael Kirchberger

Michael Kirchberger ist Agile Coach der APA-Tech und Profi zum Thema User Stories. Wir sprechen heute darüber, warum technische Spezifikationen für ein agiles Projekt nicht reichen, wie es zu schaffen ist, dass die richtigen Bilder in den Köpfen des Projektteams entstehen und dass das „Was“ in User Stories King ist und nicht das „Wie“. Klassische Kommunikationsmethoden wie das Storytelling sind bestimmend in der agilen Softwareentwicklung, und gearbeitet wird, bis der Nutzen erreicht ist. Spotlights zum Thema User Stories und konkrete Tipps – jetzt reinhören.

Michael's Buchtipp: User Story Mapping von Jeff Patton

Transcript

Was ist eine user Story und wie funktioniert diese magische Zutat der Agilität? Darüber spreche ich heute mit Michael Kirchberger, unserem Agile Enterprise Coach bei APA-Tech. 

Michael, herzlich Willkommen zur zweiten Runde und zum Thema Was ist eine gute Story? 

Hallo Clemens, vielen Dank, dass ich wieder da sein darf. 

Bisher haben wir so gearbeitet in der Vergangenheit, dass wir eine Spezifikation haben. Warum reicht das nicht mehr aus? 

Also diese klassischen Anforderungen sind eigentlich eher aus Sicht von Analysten Projekt Menschen Stakeholdern verfasst. Im Prinzip ist das eigentlich mir eine ja nein Liste, die man abhaken kann ja, das heißt, ich hab eine Liste mit ja, diese Anforderung erfüllt beziehungsweise diese Anforderung ist nicht erfüllt und das ist wichtig zum Teil für ganz klassische Verträge und das ganz klassische Projektmanagement im agilen Umfeld wollen wir allerdings ein bisschen mehr haben. 

Hä? 

Aber das klingt doch recht praktisch, weil eines Spezifikations sagten ja ganz genau, was ich bauen muss. 

Ja und Nein also? Das operative Geschäft von unseren Nutzern und unseren Kunden besteht ja nicht nur aus den Anforderungen, wenn es jetzt eine klassische Schnittstelle zwischen 2 technischen Systemen ist, wo man zum Beispiel nur Daten zwischen 2 Softwaresystemen hin und her schickt, ist eine klassische Spezifikation völlig. 

Ausreichend, wenn ich jetzt aber zum Beispiel eine Software entwickeln möchte, die den Kunden bei den Workflow unterstützt, zum Beispiel das Erfassen doch nichts druckgeräten Kundendaten, die dann irgendwie weiterverarbeitet werden, zum Teil automatisiert zum Teil ist automatisiert, dann erzählt uns der Kunde eigentlich unsere Auftraggeber eigentlich ja Geschichte und genau darum geht es nämlich zum Verstehen quasi um was es bei dieser Geschichte geht. 

Hm. 

Mhm ja, was ist denn was ist denn diese Geschichte? Was ist denn die User Story? 

Also grundsätzlich wir verarbeiten in unserem Kopf Geschichten. Ganz anders als eine technische Anforderung. Wir versuchen dann eben, diese Geschichten einzutauchen und auch diese zu verstehen. Das ist so wie also früher der Papa oder Mama etwas vor. 

Lesen hat und auch Manager können anhand von ihren Geschichten das jetzt erzählen, ihre Geschäfts besser priorisieren. Das heißt, sie können sagen, was wichtiger ist, was weniger wichtig ist als anhand einer klassischen technischen Anforderungsliste und User Stories beschreiben eben die Anforderungen und die Geschichte, also die Anforderungen an das Produkt unserer Service. Aus Sicht der Nutzer. Das heißt wie mutig, dass dieses Ding in letzter Konsequenz. 

Herr. 

Okay, das heißt, das hat einen einen ein bisschen einen psychologischen Hintergrund, um diese Inhalte besser aufnehmen zu können, so verpack ich ihnen eine. 

Ein bisschen ja. 

Nicht. 

Wie klingt denn so eine Geschichte, weil wir sind sehr theoretisch gerade. 

Wie kann ich mir das vorstellen? 

Also grundsätzlich, es gibt so einen Grund Baukasten ja, wie eine gute Sorge, Story aussehen. 

Also warum? 

Das ist immer so ein ein Basis. So wer also ich als Nutzer als wie auch immer möchte dann sagt man einen Ziel und einen Wunsch und welchen Nutzen haben soll. 

Die gute alte Formel für User Stories, wie sie in jedem Scrum Buch zu finden ist genau diese habe ich in einer Reihe von Projekten extensiv benutzt. Extensiv bedeutet, dass wirklich niemand mehr Anforderungen nach diesem Rezept schreiben wollte, weil er spätestens nach dem fünften Mal einfach zieren dies wie ein Roboter einen lückentext Verkehr. 

Aber das ist nicht der Punkt. Wichtiger ist eine Perspektive einer Person oder Roller einzufangen. Einen Zweck anstatt einer Funktion zu erklären und ein klares Ziel zu formulieren. 

Oh. 

Genau es ist aber so, dass die Story ist es geht auch immer darum, dass es ist, eine Einladung zur Kommunikation also im Gegensatz zu einer klassischen Anforderungen, die am Beginn eines Projektes erfasst wird. 

Geht es bei einer User Florida und dass die auch wachsen kann? Es geht vor allem um das gemeinsame Verständnis also im Idealfall sollte es nur eine Story geben und sowohl Kunde als Produkt, ohne als Softwareentwickler bis hin zum Betrieb sollten verstehen, um was es darin geht. Dieser klassische Formel ist so quasi immer der Anti serdat. Ich hab da jetzt so ein Beispiel ja. 

Mhm. 

Hm. 

Aus unseren Backlogs ja, also hundert möchte ich, dass mein Live Event automatisch startet, sobald ein Bild erscheint. Das ist nicht, der fehlt jetzt auch quasi auch der Nutzen aber ist schon ok und wenn das dann in der in der Story in der Deskription gut beschrieben ist was der Kunde möchte und vor allem ganz wichtig auch immer da, sagte Danz Kriterien vorhanden sind. 

Ja. 

Nämlich Akzeptanzkriterien sind jene Teile, an denen der Produkt, ohne dann den Erfolg messen kann. 

Also sprich ob irgendetwas erfüllt wird oder nicht. 

Dann ist dieser Stories ausreichend. Ich kenne Beispiele, sogar wo Produkt oder überhaupt nur wie youtube Videos aufnehmen und wenn alle das gleiche Verständnis darüber haben, was da passieren soll, ist es auch komplett ok. 

Ja, genau was kann das jetzt besser als eine Spezifikation? Was steckt da jetzt näher drinnen? 

Also ganz wichtig bei einer Story ist Produkt ohne geben keine technischen Vorgaben. 

Hm. 

Im klassischen Sinn, das heißt, jetzt wird aus einer Kundensicht das geschrieben und in sogenannten Refinement, also zuerst einmal in in in Workshops mit dem Kunden. Was bedeutet diese Story? Und dann später in Refinement mit dem Team aus diskutiert wie sieht das umzusetzen? 

Hm. 

Technische Teams lieben und hassen klassische Anforderungen. Ja, also Sie benötigen natürlich anfordern, wie sie es umzusetzen haben, aber im Agilen ist es wichtig, dass sie selbst diese Anforderungen aus den Stories ableiten und die nicht quasi aus einer Managementsicht quasi vorgegeben bekommen, wenn sie die Fachleute für das wie, wie sie es umsetzen können. Und deswegen ist es wichtig, dass sie das selbst daraus ableiten können. 

Mhm. 

Wie Sie das tun? 

Was macht denn jetzt eine User Story zu einer guten User Story? 

Herr. 

Also eine gute User Story ist es dann, wenn. 

Auch wirklich einfach und simpel akzeptanzkriterien drinnen stehen, das heißt der Produkte, ohne aus mit einfachen Worten beschrieben hat, was passieren soll. 

Mhm. 

Keine Ahnung also ein ganz klassisches Beispiel in einem Webshop zum Beispiel, wenn man einen kaufen Button klickt, dass sich die Gesamtanteil der 1 und im Warenkorb um 1? 

Geht das, ist jetzt so? 

Dass sein Lohn Level Beispiel. 

Beziehungsweise anhand dessen, dass das Team auf weiß, dass es umsetzt, anhand dieser Akzeptanz Kriterien an was sich der Product Owner dann anzieht, ob es funktioniert oder nicht. 

Hi. Wichtig ist auch, dass da in Wirklichkeit keine technischen Dinge drin stehen. Das heißt im Sinne von wir entwickelt wird. 

Mhm. 

Was das Projekt ohne schauen kann, sind zum Beispiel Rahmenbedingungen vorgeben, also im Sinne von ich keine Ahnung also man darf jetzt keine zusätzlichen Server dafür benötigen damit. 

Wir nicht mehr wissen. 

Okay, ich kann jetzt nicht da die Infrastruktur aufblasen und ich muss das auch mit einer Bestandsinfrastruktur gewährleisten. Nicht gut ist es dann zum Beispiel, wenn wenn Stories nur aus einzelnen Wörtern geben, die auch sprachlich Canon sind geben. Ich hab da auch ein Beispiel mitgebracht. Ich hoffe, ich trete jetzt keinen niemanden auf die Füße, aber ich hab so ein Beispiel hieß die Story einfach nur der eben Video info. 

Wenn du jetzt irgendwas drauf sieht, weiß kein Mensch. 

Aber das ist keine Story, oder? 

Mensch, was ist? 

Mhm. 

Da sind dann die Akzeptanzkriterien unzureichend gewesen, dann muss man halt dann rauf schauen, das ist dann die Aufgabe von Scrum Master, aber auch vom Team, den Product Owner, darauf aufmerksam zu machen mit das versteht keiner. 

Ja, ich kann mir vorstellen bei der anderen sorry, war mir halbwegs klar was zu erreichen. Wie sollen wir das tun? 

Will und der der Weg und die technische Umsetzung ist, dann ist dann Aufgabe der Entwickler oder des Teams aber in diesem Fall ist es natürlich wesentlich schwerer, das heraus zu lesen, aber das ist auch keine Story, oder? 

Es ist kein. Es wurde als Tore angelegt, aber vom Titel her ist es dann keine Story mehr. 

Okay. 

Dahinter stand dann in Wirklichkeit schon viel mehr und ein größeres Ding. Aber man kommt nicht heraus. 

Natürlich. 

Im. 

Muss eine Story immer ganz genau nach dieser Lehrbuch Formel? 

Aufgebaut sein. 

Am eine Story muss nicht also das ist meine persönliche Meinung. Da gehen aber die Meinungen auch in der agilen Welt auseinander. Nicht unbedingt noch diesen Lehrbuch aufgebaut sind. Der Kern dessen ist. Es muss alles drinnen stehen, damit jeder, der mit dieser Story arbeitet, Einverständnis hat, wie es ist. Es muss im Kopf sich eine Geschichte formen, dass ich weiß, wie es funktioniert. Das ist, wenn man jetzt ein Beispiel nimmt zum Beispiel. 

Bei. 

Einer Druckfunktion jeder jeder Software, jeder, der mit irgendeiner Software arbeitet, kann sich ungefähr vorstellen werden druckfunktion aussieht, das ist egal, ob das aus einem Word, einem Excel oder irgendeiner sonstigen Applikation herauskommt und genau so ein Bild muss ich schaffen gar nicht einmal wie das technisch und dieses Bild muss ich schaffen. Das kann ich schaffen, indem ich es beschreibe. Das kann ich schaffen, indem ich Skripals hinzufügen. Das kann ich schaffen, indem ich ein kurzes Video mache oder einen Klick Dame. 

Mhm. 

In irgendwelchen Tools erzeuge und das zu einer Story hinzufügen. 

Mhm. 

Mhm. 

Und wesentlich ist eben auch das Team muss wissen, dass es umsetzt. 

An was wird der Kunde beziehungsweise der Product Owner also der, der das quasi übernimmt? 

Abnehmen können, dass es funktioniert oder nicht funktioniert hat die Story. 

Und da sind dann die Akzeptanzkriterien. 

Die Akzeptanz der der. 

Fassen wir also zusammen eine You Story soll Anstoß zu einem interdisziplinären Austausch liefern. Sie kann neben der prägnanten Zusammenfassung in einem Satz viele Dinge enthalten, wie zum Beispiel Skizzen, Krieg damals oder Videos mittels Akzeptanzkriterien wird ein gemeinsames Verständnis zwischen den Produkten und dem Team hergestellt. Ab wann die Umsetzung einer Story erfolgreich abgeschlossen ist und eine Story ist Einladung zur Kommunikation die Erklärung was das genau bedeutet? 

Hi. 

Hi. 

Oh. 

Lasse ich jetzt aber Michael. 

Es geht eben darum, dieses gleiche Verständnis aufzubauen, und es geht darum, dass die alle, die damit arbeiten, ein gleiches Bild davon haben, also wenn dann jetzt mal ich habe auch gesagt zum Beispiel der Betrieb für den Betrieb ist es auch wichtig, die Geschichte dahinter zu verstehen. Wenn wir jetzt zum Beispiel eine Software entwickeln und klassische technische Anforderungen an eine Software Entwicklung haben und diese dann einen Betriebsmitarbeiter vorlegen. 

Mhm. 

Dann hat sich der wahrscheinlich schon meistens davon verabschiedet. Wenn der aber versteht, was den Kunden wichtig ist und wenn er versteht den Geschäftsführer ist ganz wichtig, dass dieser Teil der Infrastruktur, der Teil der Software funktioniert. Dann kann der es auch leichter daraus ableiten, was für Backupsysteme Monitor, Systeme usw jetzt wie dimensionieren muss. 

Mhm. 

Als wenn er quasi nur liest, welche Software Komponenten zur Verfügung gestellt werden müssen seitens einer Softwareentwicklung. 

Aber wann findet denn diese Kommunikation statt? Wann wird denn geredet über die Story? 

Da gibt es mehrere Methoden. 

Wie man Produkte entwickeln kann, also eines ist zum Beispiel das User Story Mapping, wo in einer Runde von Stakeholdern oder Usertask und Aktivitäten aus Benutzersicht sequentiell angeordnet werden also man kann sich das vorstellen sowie ein Storyboard bei einem Zeichentrickfilm. 

Hm. 

Mhm, wie sich der Benutzer und jetzt richtig aus Benutzersicht und nicht das Domäne oder sonstige nicht durch diese Applikation durch bewegt und aus denen heraus kann man zum Beispiel an die einzelnen User Stories ableiten. 

Mhm. 

Wenn das jetzt gesagt. 

Haben eine Druck Funktion irgendwo wird es dann geben. 

Am Ende eines Word Dokuments möchte ich, dass dein Ding dann ausdrucken und dann gibt es einzelne User Stories, die dann eben sagen ich kann einen einen Drucker auswählen oder ich kann einen den Druck Button wählen oder ich kann sagen es ist schwarz, weiß oder fertig. 

Wie wissen wir, dass, dass wir alles erwischt haben und dass wir fertig sind? Mit den User Stories? 

Use Weiß sind wahrscheinlich nie fertig. Wir haben in agilen ja eine einen Zyklisches arbeiten, das heißt, wir arbeiten mit Prinz und in Wirklichkeit arbeiten wir so lange, bis der Kunde seinen Nutzen erreicht hat. 

Es kann sein, dass zu Beginn bei einem User Story Mapping herauskommt, dass der Kunde gerne ein grafisches Interface für irgendetwas hätte und im Laufe des Projektes kommt man drauf. In Wirklichkeit reicht es, wenn irgendwo ein Report oder sonst irgendetwas automatisiert zeitgesteuert erzeugt wird, ohne dass es ein grafisches Interface dafür gibt. 

Mhm. 

Hm. 

Wenn der Nutzen erreicht, ist das Projekt eigentlich zu Ende. 

Hast du zum Abschluss vielleicht noch einen Buchtip zu dem Thema User Stories? 

Also wenn irgendwer Zugang zu einem Scrum Buch hat, bringt einer Entwicklungs Abteilung vorbeigehen jeder hat irgendwo irgendeinen Stehen im Notfall als Monitor Ständer, dann kann man dort einfach reinschauen. Es gibt mindestens ein bis. 

Hundert Seiten, wie man eine User Story machen, was mir sehr gut gefällt, ist das Buch User Story Mapping von Jeff Patton. Dort habe ich sowohl diesen diesen Ganzen den ganzen Weg drinnen von der Idee über diese User Story Map wieder und eine user Story aufgebaut ist bis hinzu den klassischen wies dann umso. 

Bitte. 

Super vielen, herzlichen dank Michael schön, dass du wieder dabei warst bis zum nächsten Mal. 

Ja gerne.