Wie schreibt man User Stories richtig?

Kai

User Stories werden oft im gleichen Atemzug genannt mit agilen Methoden und wir kümmern uns heute um ein paar Mythen, denn die werden ganz oft falsch verwendet und du kriegst in diesem Podcast mit. Was ist eine User Story und wie schreibt man die eigentlich richtig? Und wie spart man unglaublich viel Zeit beim User Story schreiben denn falls du da eine riesen lange Liste gerade vor dir hast, die so eine Anforderung ausmacht, dann haben wir da eine kleine Überraschung für dich in petto.

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

Kai

Herzlich willkommen zum Agile Growth Podcast. Hier sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen Agiler Vorgehensweisen in der Praxis einzulösen, ohne IT WIssen vorauszusetzen.

Jasmine

Ganz, ganz oft, wenn wir beim Kunden unterwegs sind – ob jetzt in der IT oder nich, in der IT kriegen wir so was zu hören wie: Ja, wir machen ja jetzt auch dieses Scrum. Wir benutzen Jira und schreiben User Stories. Aha, okay. Und was hat das jetzt konkret mit Scrum zu tun? Grundsätzlich schon mal gar nichts, oder wir kriegen die Fragen. Ja, irgendwie sagt das Management jetzt, wir dürfen nur noch User Stories schreiben, aber ich weiß gar nicht, was das ist.

Jasmine

Dieser Begriff User Stories, der geistert so durch die Hallen und Räume, sobald irgendjemand anfängt Agil zu arbeiten oder mit Scrum zu arbeiten. Und wenn du noch nicht so viel damit zu tun hast. Ganz kleiner Disclaimer an der Stelle – Jira ist Ticket Management Tool, das ganz viel kann. Viele Firmen benutzen es. Man muss das nicht benutzen um Scrum zu tun, aber man kann gibt es in gut gibts in nicht so guter Implementierung gibt es in It, gibt es nicht in IT.

Jasmine

So, das dürfen wir gerade mal vergessen, weil das hat nichts mit Agilität zu tun. Also welches Werkzeug ich benutze, hat ganz ganz wenig damit zu tun wie Agil ich bin und ob ich User Stories schreibe oder nicht, hat auch ganz wenig damit zu tun wie agil ich bin. Aber die meisten Teams, die Agil eine Produktentwicklung vorantreiben, werden irgendwann mal für sich ein Backlog erstellen. Und ein Backlog ist eine geordnete Liste an Anforderungen an unser Produkt. Und in diesem Backlog sind natürlich Einträge.

Jasmine

Und da hilft es mir, eine gewisse Idee davon zu haben, wie ich diese Einträge schreiben kann. Und wenn ich jetzt gucke, was steht denn normalerweise so in den Backlogs, dann sind das nicht nur User Stories, weil das ein sehr spezifisches Format ist, das aber durchaus Sinn macht. Deswegen wollen wir ganz, ganz explizit auf dieses Format eingehen in diesem Podcast. Aber bevor wir da hin kommen, vielleicht noch was kann sonst noch so in dem Backlog drinstehen?

Jasmine

Da können zum Beispiel natürlich auch Fehler an unserem Produkt drin stehen. Das werde ich nicht unbedingt in diesem Format User Story machen. Da können System-Anforderungen drinstehen, oder da kann auch technische Schuld drinstehen. Wenn ich schon lange irgendwas an diesem Produkt mache, dann habe ich vielleicht irgendwo Schuld aufgeladen. Das wird auch irgendwie beschrieben sein, aber vielleicht nicht unbedingt in diesem User Story Format. Warum dieses User Story Format aber trotzdem sehr, sehr hilfreich ist, hilft vielleicht, wenn man mal zurück guckt wo kommt Agilität her oder wo kommt Scrum her und es kommt aus der IT und da hat man ein Format gesucht, das den Entwicklern hilft.

Jasmine

Im Prinzip Empathie zu entwickeln mit dem Endnutzer.

Kai

Wir haben das mittlerweile in unserer Produktentwicklungskultur viel viel mehr drin. Es gibt ja so Leute, die sich darauf spezialisieren, UX genannt, also User Experience, die sich da ganz viel mit beschäftigen. Wie erlebt eigentlich unser Anwender das Produkt oder das System? Und wenn man so ein bisschen zurück guckt, damals gab es das halt nicht in der Form und ich habe ja auch Informatik studiert und bei mir war das am Anfang auch so. Ich als Programmierer habe ganz viel gedacht in so inneren Repräsentationen von meinem Produkt.

Kai

Also sprich eher so auf der Ebene von Quellcode und Abstraktionen und Schichten und Datenbank-Layer und all diesen Dingen, die ich als Informatiker eben kann. Damit war ich aber relativ weit weg von dem Problem meines Anforderers, also dem Problem meines Kunden, sondern war eher so in diesem Lösungs-Gebäude drin. Und insofern ist das praktisch für mich, wenn ich als derjenige, der das umsetzen soll, noch mal in den Hautsack des anderen rein schlüpfen kann, desjenigen dessen Probleme lösen will, also unserem Kunden und da mehr verstehe, was will der eigentlich und wieso überhaupt?

Kai

Und jetzt haben wir ja auch festgestellt, dass das ganz ganz schwierig ist, in Textform irgendwie Anforderungen aufzuschreiben, also so ein Fein Konzept aufzuschreiben, wo ganz detailliert Details drin stecken, weil das so ein bisschen dieses Flüster-Post Spiel ist, wo man ganz ganz viele Dinge miteinander verzahnt. Und da helfen uns eben User Stories etwas anderes zu tun.

Jasmine

Und in meiner Erfahrung ist es eigentlich egal, ob du jetzt in der IT unterwegs bist oder in einer anderen Branche unterwegs bist. Dieses sich in die Schuhe des End-Nutzers zu begeben ist unglaublich schwierig. Also selbst wenn ich jetzt irgendwie im Human Resources unterwegs bin, eine Trainings-Organisation habe, dann hilft es mir einfach durch ein Format gezwungen zu sein vom Endbenutzer her zu denken, weil wie oft kommt das vor? Und das kommt bei mir ganz ehrlich ganz oft vor, dass ich eine geniale Idee habe.

Jasmine

Und die ist so genial, dass ich anfange Anforderungen aufzuschreiben. Wie wir diese Idee jetzt umsetzen und in meinem Anforderungen aufschreiben. Wie wir diese Idee umsetzen, vergesse ich komplett zu beachten: für wen ist denn das eigentlich? Und der Punkt von genialen Ideen ist ganz oft – Die entspringen ja aus unseren eigenen Bedürfnissen. Aber mein Bedürfnis ist nicht unbedingt das Bedürfnis meines Nutzers oder meines Kunden. Also wenn ich – und wir geben ja ganz viele Scrum Master Trainings – wenn ich ein Scrum Master Training gebe und ich da eine geniale Idee habe und anfange runter zu schreiben, wie muss ich denn das jetzt genau umsetzen?

Jasmine

Was für Material brauche ich und so weiter. Dann kommt Kai ganz oft und sagt mir: Du Jasmine. Was soll denn ein jemand, der neu mit Scrum einsteigt, dabei überhaupt lernen? Da bin ich bisschen sauer auf Kai, aber die Frage ist gut, weil oft ist es ja meinem Bedürfnis entsprungen und viel zu weit weg von dem, was ein Nutzer bräuchte.

Kai

Und da hat sich jetzt ne User Story als hilfreich erwiesen. Und machen wir’s mal konkret: Was ist das eigentlich? Wir haben es gerade gehört. Das ist eine Art Empathie-Hilfe, so eine Story. Das ist aber eigentlich ein natürlich-sprachlicher Satz, also ein Stückchen Text, das irgendwie beschreibt: Wer möchte was wozu? Und so nutzen manche auch ein bisschen, wie so die Stützräder am Fahrrad, wenn man Fahrradfahren lernt, eine Zeit lang so ein Format und das nennt sich “als wer möchte ich was um wozu?” Also zum Beispiel könntest du sagen: Als Agile Growth Podcast Hörer möchte ich verstehen, was eine User Story ist, um

Kai

Bald in meinem Arbeitsalltag diese sinnvoller nutzen zu können. Dann hätte ich also festgelegt, wer möchte das haben, nämlich du als unser Hörer? Muss ich vielleicht noch ein Bild innerlich haben – wer bist du als unser Hörer? Also Jasmine ich machen uns so eine Vorstellung davon. Wie siehst du jetzt aus? Wo hörst du uns gerade beim Kochen oder beim Fahrradfahren? Und dann haben wir das “wer” klar. Und dann das “was”. Was ist eigentlich das, was da gebraucht wird?

Kai

Die Funktionalität, das Bedürfnis dahinter? Und wozu? Was ist denn die Absicht? Was möchte derjenige, wenn er dann diese Funktion hat? Und das alles wird eben beschrieben. Und du merkst schon bei diesem Ganzen, wie lange man darüber sprechen kann. Es ist eigentlich ein Satz, der ein Versprechen über ein Gespräch darstellt. Also der ist so unkonkret, dass ohne weitere Unterhaltung darüber,  man das auch gar nicht umsetzen kann.

Jasmine

Wobei der aber auch so konkret ist, dass das bei mir schon ganz, ganz viele Ideen triggert, nämlich als Kai gesagt hat: Wer will das, unser Podcast Hörer? Da brauchen wir vielleicht ein inneres Bild von und dann hat Kai schon gesagt: Ja, warum hörst du das? Vielleicht beim Kochen oder beim Fahrradfahren? Ah, spannend. Okay, das heißt, du hast keine Möglichkeit, was aufzuschreiben. Du wirst da nichts neben dir haben. Und stimmt, wir gehen davon aus, dass niemand von euch oder dass du auf jeden Fall nicht an deinem Schreibtisch sitzt und jetzt etwas schreiben möchtest.

Jasmine

Das heißt, wir werden die Information so verpacken müssen, damit sie leicht konsumierbar ist – um was geht es wirklich? Um das Verständnis einer User Story. Und dann macht das bei mir auch schon wieder ganz ganz ganz viele Knöpfe auf. Oh, müssen wir dann was zum Backlogs verstehen, was ich vorher schon angedeutet habe, oder? Oder nicht? Oder wo geht das hin? Und der schwierigste Teil ist immer das: Wozu möchtest du das verstehen?

Jasmine

Wir haben jetzt angenommen, damit du das besser in deinem Arbeitsalltag umsetzen kannst, das heißt, wir brauchen auch ganz konkrete Umsetzungs-Tipps in dieser Podcastfolge drin. Also, wie du siehst, es ist ein Satz, der aber so viele Informationen enthält, dass es bei mir schon die Kreativität schürt. Das heißt, kann ich das direkt von diesem Satz irgendwie in die Umsetzung gehen? Nein, es ist schwierig, aber ich kann mit Kai drüber anfangen zu reden. Wie muss denn diese Podcastfolge jetzt konkret aussehen, damit sie den Nutzen generiert

Jasmine

den wir generieren wollen?

Kai

Also das Ding öffnet quasi einen Korridor von Kreativität. Und wenn man dabei natürlich Details herausfindet, dann darf man die auch aufschreiben und dann kann man entsprechend festlegen wann ist denn diese User Story fertig? Und eine ganz nette Merkhilfe sind die drei C dabei. Also das erste C ist Englisch für Card. Also eine User-Story passt auf eine Karteikarte. Das heißt also wirklich, das ist ein kurzer Satz. Das ist nicht eine halbe DIN A4 Seite geschrieben, sondern einfach mal so ein halber Satz

Jasmine

Und mit einem dicken Stift.

Jasmine

Also nicht eine Karteikarte mit so einem dünnen Bleistift. Es ist eine Karteikarte mit einem dicken Stift.

Kai

Das zweite ist in der Story selber steckt ja gar kein “Wie” drin. Also ich habe da drin. Wer möchte was? Wozu? Ich habe kein Wie drin. Das heißt, dass ganz viel Musik da drin wie die Lösung aussieht. Und das hat Jasmine ja gerade auch schon angesprochen, wie genau das umgesetzt wird, zum Beispiel hier die Podcastfolge ist ja dann etwas, was sich durch den Raum unserer Kreativität füllt. Und dann sind wir beim zweiten C und das steht entsprechend für Conversation.

Kai

Also eine User Story führt zu einem Gespräch. Wenn man das jetzt in der Praxis sieht, wie machen das dann Agile Teams? Die haben ein Gespräch im Idealfall zwischen ihrem Anforderer, also dem Kunden und den Entwicklern. Also Fachexperten und Entwickler müssen täglich zusammenarbeiten, steht im agilen Manifest – da trifft das also aufeinander, nicht nur im heterogenen, cross-funktionalen Team, sondern auch mit den direkten Kunden-Dialogen. Also Scrum nennt sowas Backlog Refinement, also Backlogs Verfeinerung. Da, wo wir mehr verstehen, was genau bauen wir denn eigentlich?

Kai

Und dieses Gespräch ist eben wichtig. Und das, was wir dabei rausfinden, das halten wir fest im dritten C. Das steht nämlich für Confirmation. Also wie weiß ich eigentlich, dass diese User Story fertig ist? Wann sagt Tante Erna mir – Das ist immer so mein prototypischer Name für den Kunden, für das Gegenüber. Jemanden, der also nicht diese ganze Technologie versteht oft, sondern einfach so eine Fach-Domäne. Wann sagt er, ist das fertig?

Kai

Wann akzeptiert das mein Kunde als abgeschlossen? Akzeptanz-Kriterien könnte man das auch nennen. Wann ist diese User Story fertig? War das unsere Podcastfolge fertig? Zum Beispiel wenn du ganz konkretes Wissen bekommen hast und konkrete Tipps, wie du das anwenden kann, bei dir könnte. Bei uns, das Confirmation Kriterium sein.

Jasmine

So, jetzt hast du schon gehört, was ist diese User Story? Wie baut sich die auf? Es ist ein Satz, der diese drei Aspekte – wer möchte was und wozu – abdeckt. Und die drei Cs als Merkhilfe: Card, Conversation und Confirmation im Sinne von wie setze ich das um? Oder was ist wichtig dabei, wie wir das jetzt meistens angehen ist – Wir schreiben eine sehr, sehr große User Story. Wir könnten eine User Story für diesen Podcast schreiben. Als Agile Growth Podcast-Hörer möchte ich gerne sehr viel Input zu Agil, damit ich meinem Wachstum begleitet werde.

Jasmine

Wäre wahrscheinlich unsere User Story für diesen Podcast und die ist noch relativ schwach, weil dies gerade so aus meinem Kopf entsprungen, die dürften wir jetzt schärfen. Und darunter kann mir natürlich dann ganz viele User Stories für jede einzelne Podcastfolge machen. Und wir könnten sogar noch mehr vertiefen, indem wir ganz viele User Stories für die einzelnen Kapitel einer Podcastfolge machen und somit eine Struktur da reinbringen. Das heißt, ich kann die User Stories auch immer wieder, man nennt das dann splitten, kleiner machen, Teilaspekte davon rausnehmen.

Jasmine

Das ist so was, was man zum Beispiel in einem User Story Map machen würde, was wiederum einfach nur eine Empathie-Hilfe ist, um von dem Endnutzer auf das ganze Produkt zu gucken. Und das ist natürlich ein bisschen einfach, wenn ich jetzt ein Softwareprodukte habe, weil ich das einfacher beschreiben kann. Aber ich habe das auch schon bei Lern-Produkten gemacht. Vom Ende User auf die gesamte Lern-Reise zu gucken, die jemand macht, wenn er in ein Training geht oder wenn er in eine ganze Trainings Serie geht.

Jasmine

Aber man kann das auch nur mit einem Training machen. Was geschieht vorher? Was geschieht nachher? Von dieser End User Perspektive aus? Und da steckt ganz viel – wir sind dann ganz viele nennen das ein Problem Raum. Wir beschreiben den Problem Raum sehr sehr genau, damit wir kollektiv mit unserer kollektiven Intelligenz als Team in den Lösungsraum gehen. Das heißt wir möchten als Userstory nicht unbedingt haben. Als Nutzer der Software, was sowieso eine sehr sehr sehr schwache Persona wäre, möchte ich, dass dieser Button grün wird, damit ich ihn besser sehe.

Jasmine

Das wäre ja schon eine Lösung. Was ich da vielleicht haben könnte ist als Barbara Backoffice möchte ich, dass die Buttons in der Software gut sichtbar sind, weil ich wenig Zeit habe, wenn ich die Software bediene und gleichzeitig am Telefon bin. Das heißt, ich habe da keine Lösung drin. Ich sage nicht, es kann ja sein, dass der Button grün wird, aber ich weiß, warum Barbara Backoffice das will. Ah ja. Barbara Backoffice ist gleichzeitig am Telefon und muss rum tippen und hat wenig Zeit.

Jasmine

Und die hat auch nicht Zeit, da drauf zu gucken. Das sag dem oder derjenigen, die dann das Design und in die Lösung geht, so viel mehr aus als “es muss grün sein, damit ich sehen kann.”

Kai

Und jetzt gibt es immer wieder diese Frage, die kriegen wir auch in Trainings ganz oft. Wie schreibe ich denn dann jetzt eine gute User Story? Und im Prinzip, wenn du diese Frage hast, könntest du auch sagen – dann gibt es wahrscheinlich ein Problem in der Beziehungsqualität zwischen den Anforderern und deinem Team. Denn eigentlich geht es hier um dialog-basierte Produktentwicklung. Dieser kleine Fetzen Text, der da auf so einer Karte drauf steht, der soll einfach nur zum Dialog anregen. Das heißt, von der Formulierung her ist es eigentlich total egal, wie du so ein Ding aufschreibst.

Kai

Und es geht nicht darum, da einen ewig langen Monolog zu machen. Und das sieht man auch manchmal in Teams, die noch neu sind, in Agilität oder wenn wir so reinkommen im Coaching. Die schreiben dann seitenweise Anforderungen in Tickets rein und das sind dann deren User-Stories. Oben steht so ein Satz als soundso und so möchte ich das und das. Und darunter kommt dann Spezifikation nach Spezifikation nach Spezifikation. Und da merkst du, dann fangen die Teams auch an zu chatten über irgendwelche Tickets und schreiben dann da Kommentare rein und so weiter und entgehen dabei dem Dialog und andere Teams, die das sehr Agil tun, die wissen, dass die wichtigste Art der Kommunikation von Angesicht zu Angesicht stattfindet, weil wir eben so viel mehr an Bandbreite haben, an Informationen, die wir im direkten Dialog miteinander haben.

Kai

Dass wir die nutzen wollen, um ein möglichst tiefes Verständnis zu haben, um das richtige an Wissen zu produzieren. In unserem Quellcode zum Beispiel. Quellcode ist ja auch so amalgamisiertes Wissen und in unserem Produkt soll die bestmögliche Lösung rein fließen . Und die kriege ich dann hin, wenn die Leute, die das Produkt brauchen, mit denen sprechen, die das bauen und nicht wenn ich eine Abstraktionsschicht habe von Text.

Jasmine

Und um das noch mal zusammenzufassen – Es ist nicht schlimm, wenn die Spezifikationen irgendwo stehen. Das Schlimme daran ist, wenn sich das irgendjemand ausgedacht hat und hingeschrieben hat. Das heißt oder das schlimme daran, wenn sie schon in der User Story drin stecken. Die User Story soll der eine Satz sein, der unsere Kreativität anregt. Also als Barbara Backoffice möchte ich gut sichtbare Buttons, weil ich wenig Zeit zur Bedienung habe, wenn ich am Telefon bin. Und da kann das sein, dass wir jetzt in die in die Kommunikation gehen, miteinander, aber vielleicht auch mit prototypisch Barbara Backoffice.

Jasmine

Vielleicht fragen wir einfach drei Backoffice Mitarbeiterinnen. Wie sieht denn das aus, wenn du damit arbeitest? Und da sehen wir: Boah, die haben irgendwie sieben Fenster gleichzeitig auf, wenn sie am Telefon sind, müssen alle Programme gleichzeitig bedienen und dann halt unser Programm auch noch. Und dann brauche ich vielleicht eine Telefonansicht. Dann geht es gar nicht darum, dass wir einzelne Buttons umgestalten, sondern es geht darum, dass wir eine Telefon Ansicht des Programms machen oder oder oder oder.

Jasmine

Oder es geht einfach darum, dass wir den Button wirklich grün machen. Das würden wir in der Kommunikation mit dem Endkunden rausfinden und in der Kommunikation miteinander. Und wenn wir darüber reden und uns das dann aufschreiben, dann ist das was ganz anderes, als wenn das jemand aufgeschrieben hat, ich das lese. Und das führt oft zu ganz vielen Missverständnissen. Deswegen ist dieser Konversation Part ganz, ganz wichtig in einer empirischen Produktentwicklung. Wir schaffen hundertprozentige Transparenz, damit wir inspizieren und adaptieren können.

Jasmine

Das können wir nur zusammen, nicht alleine.

Kai

Wir hatten hier mal ein Interview mit Marc Bless, der hat auch mal ein Buch geschrieben über Scrum in der Medizintechnik. Jetzt könnte man ja sagen: Okay, aber wenn jetzt in diesen User Stories nicht so richtig spezifiziert ist, was wir bauen sollen, kann ich das zum Beispiel Medizintechnik Bereich machen, Agil arbeiten oder kann ich das im Luft und Raumfahrt Bereich machen? Wenn ich ganz konkrete Dokumentation brauche, gehört die einfach an eine ganz andere Stelle nämlich, dann verorte ich die in einem Scrum Rahmenwerk in der Definition Of Done, also dem Kriterium, was fertig heißt.

Kai

Da kann dann durchaus drinstehen, wir haben irgendeine ISO Norm erfüllt. Und an der Stelle ist vielleicht auch ganz viel textliche Dokumentation entstanden, die das noch mal für die Nachwelt irgendwie verfasst. Es ist aber einfach dann andersherum. Es ist quasi ein Liefer Gegenstand, der nachher aus der Kreativität am Anfang entstanden ist und nicht andersherum. Dass ich mir vorher ein riesen Kopfzerbrechen als ein einzelner Experte, was genau die beste Lösung sein soll. Und danach ein Team, das nur noch umsetzt, sondern eben dieses Führen über die Einladung zum Gespräch.

Kai

Insofern kann man auch sagen Agile Teams quatschen viel mehr.

Jasmine

Aber dadurch bauen wir das Richtige in der richtigen Qualität und reduzieren sehr, sehr, sehr viel Waste auf dem Weg. Das heißt, das kann sich anfangs uneffizient anfühlen, weil ja, wir gehen viel mehr in den Dialog. Das ist aber hinten raus oder mittelfristig sehr viel effizienter, weil wir den ganzen Quatsch und die ganzen Missverständnisse eben nicht mehr bauen, sondern früher rausfinden. Um das jetzt noch mal so zusammenzufassen. Viele Agile Teams haben ein Backlog, eine geordnete Liste an Anforderungen an das Produkt.

Jasmine

Da können ganz viele verschiedene Dinge drinstehen, unter anderem User Stories. Nicht alles was da drinsteht, ist eine User Story, auch wenn Jira das so nennt. Wenn ich zum Beispiel eine System Beschreibung da drin habe, weil das System das einfach braucht, dann bitte nicht als User Story formulieren. Es gibt ganz komische User Stories. Wenn ich aber einen konkreten Umsetzungwunsch ein Feature da drin habe, dann nützt mir die User Story unglaublich. Wenn ich da eine User Story schreibe, ist das nur ein Versprechen für eine Konversation.

Jasmine

Das heißt das ist eine Anforderung an unser Produkt. Wirklich aus der Brille des Endkunden raus geschrieben, das uns helfen soll in Konversationen zu gehen und unsere kollektive Intelligenz und Kreativität zu nutzen. Sobald wir in Konversation gegangen sind, können wir natürlich spezifische Anforderungen an diese User Story dran schreiben. Dann werden wir uns auch alle erinnern, was wir uns überlegt haben. Das sind dann die sogenannten Akzeptanz-Kriterien. Also wie teste ich, dass wir fertig sind mit dem was wir denken, dass unser End-User braucht?

Jasmine

Eine User Story ist nichts anderes als eine Hypothese und es bleibt eine Hypothese, bis der User das getestet hat und sagt – Jo, das ist das was ich brauche oder noch nicht ganz. Und beides ist okay. Wir sind in einem komplexen Raum, das heißt, wir können nicht immer alles 100 Prozent perfekt haben. Das ist einfach natürlich. Wir müssen vielleicht noch mal zurückgehen ans Reißbrett, noch mal ein bisschen was ändern an unserer Idee schleifen, noch mal ausliefern. Und beim zweiten oder dritten Mal sagt unser End User Genau das habe ich gebraucht.

Jasmine

Also Akzeptanzkriterien sind die konkreten Anforderungen, die wir besprochen haben an unsere User Story. Und dann habe ich noch die Definition Of Done, unsere gemeinsame Anforderungen an Qualität für jede einzelne User Story und für jedes einzelne Ticket in unserem Backlog. Das heißt, das gilt über alles hinweg. Alle Anforderungen, die ich habe an Dokumentation, an Qualität etc. steht in unserer Definition Of Done. Da haben wir auch eine Podcastfolge dazu gemacht. Aber jetzt hast du so trennscharf die unterschiedlichen Abgrenzungen.

Jasmine

Die sind am Anfang ein bisschen schwierig zu verstehen. Sobald man anfängt, damit zu arbeiten, macht es aber ganz, ganz viel Sinn, warum das getrennt ist und warum wir da sehr trennscharf unterwegs sind.

Kai

Diese Themen vertiefen wir natürlich auch in unserem Certified Scrum Master Seminar und auch im Advanced Certified Scrum Master Seminar noch mal, dass du diese gleiche Klarheit und auch noch so das Handwerkszeug dazu lernst, damit du einen Product Owner darin auch unterstützen kannst, das entsprechend zu nutzen. Und wir hoffen, du hast jetzt einen guten Überblick gekriegt über das Thema, denn eigentlich wird das viel zu heiß gekocht, als es gegessen wird. Denn ja, es geht darum, miteinander zu sprechen, das Richtige zu bauen klingt trivial, ist aber in der Praxis ganz oft nicht der Fall.

Kai

Insofern die große Einladung zum Gespräch, die wir hier heute aufgemacht haben mit dir. Und wir freuen uns, dass du in dieser Folge wieder zugehört hast beim Agile Growth Podcast.

Jasmine

Das war unser kleiner Impuls zum Thema User Stories. Wenn du Leute kennst, die User Stories falsch benutzen oder noch viele Fragen haben zu genau diesem Thema, dann darfst du diesen Podcast natürlich unglaublich gerne weiterempfehlen. Und ich freue mich total, wenn du nächstes Mal wieder mit dabei bist beim Agile Growth Podcast.