Damit meine ich nicht, dass man morgens bei 09:00 Uhr beim Kaffee sitzen sich denkt, warum bin ich eigentlich hier, nein, sondern warum diese User Story Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Ein herzliches Hallo zum Coding Buddies Podcast. Ich hoffe es geht dir gut, liebe Zuhörerin, lieber Zuhörer und du kannst der neuen Folge ganz entspannt lauschen und damit begrüße ich natürlich auch den Tino, der hier nicht fehlen darf.
Tino Moin Moin Fabi, Was geht ab, was geht ab? Ja ich würde sagen es ist Weihnachtszeit, ich habe Urlaub mir geht's gut, was soll man dazu noch sagen? Klingt perfekt? Auf jeden Fall. Ja, die Weihnachtszeit ist auch schon ziemlich fortgeschritten.
Ja, wir sind ja schon fast durch, damit eigentlich schon so gut wie fertig mit dem Gröbsten, das ist gut, kann mich jetzt einfach nur zurücklehnen, ja dann lehn dich zurück, wir haben ein spannendes Thema heute mache ich ist auch mehr so ein lockerer Talk würde ich sagen, ist jetzt kein technischer Talk, aber trotzdem ein sehr wichtiges Thema und.
Das coole dabei ist, das Thema stammt nicht von uns, sondern es wurde vorgeschlagen beziehungsweise sich aus der Community gewünscht, denn wir haben vor einer Weile eine Nachricht bekommen, von der Veronika, vielen Dank dafür noch mal, denn sie hat gesagt, dass unser Podcast bei ihr jetzt mittlerweile ein fester Bestandteil ist und wir coole Insights geben. Also Veronika, vielen, vielen Dank dafür, dieses wunderbare Feedback und du hattest dir
gewünscht, weil wir das vor. Jahren also nicht, aber vor einer Weile in einer Folge mal angerissen hatten. Und zwar das Thema User Stories, dass wir da quasi einfach mal n bisschen näher drauf eingehen, wie wir das ganze betrachten, was gute User Stories sind, was so Duschen don't sind und das würde ich halt sehr gerne heute mit dir besprechen, das heißt wir gehen auch wieder so n bisschen in die agile Welt rein. Oh yeah, da können wir ja auch schon mittlerweile Bände
erzählen. Also was meinst du, wollen wir das so machen, dann würde ich sagen starten wir da auch einfach direkt rein finde ich gut finde ich gut lass uns das war würde ich sehr gerne versuchen so folgende Fragen so n bisschen ich hab mir mal überlegt was für fragen wir denn mit dieser Folge quasi beantworten könnten und als erstes natürlich warum überhaupt user Stories was sind User Stories auch noch mal kurz und warum sind sie so wichtig? Das ist ja eigentlich so die Kernfrage.
Warum werden sie verwendet? Warum sind wir auch der Meinung, dass es gut ist, mit User Stories zu arbeiten, um das einfach n bisschen ja herauszukristallisieren und dann vor allem, was sind so häufig Probleme die uns begegnet sind, die wir selbst versuchen zu vermeiden, weil man sollte denn natürlich auch versuchen, diese Probleme zu vermeiden.
Und was ich sehr cool finde würde, und das gibt auch einen selbst, immer noch mal so einen erleuchtenden Moment, dass wir uns überlegen, was könnten so Tipps sein für Entwickler oder auch Pos, also wie man bessere User Stories schreiben könnte, dass wir das am Ende noch behandeln. Ja, und natürlich immer auch unsere eigenen Erfahrungen mit einbringen. Ich habe, da du ja auch schon einiges erlebt, sowohl Gutes als auch vielleicht nichts ganz so
gutes und. Dass man da einfach noch mal vielleicht aus dem Nähkästchen plaudert. Ich hör mal kurz mein Nähkästchen. Hol mal und ich würd sagen, jetzt geht es dann auch los. Also fabi, erzähl doch mal. Was sind User Stories aus deiner Sicht allgemein? Ja. Definiere es mal. User Stories ist im Endeffekt so, also so würde ich das beschreiben. Also ist ne die Sicht des Endanwenders über die Anforderung. Und das Ganze in Form einer
Beschreibung und sozusagen. Also du hast jetzt eine Anforderung, also eine Art Feature oder ein Teil Feature und das wird beschrieben über eine bestimmte Art und Weise aus Sicht des Endnutzers und ich finde da ist es auf jeden Fall sehr, sehr wichtig und den Tipp möchte ich auch gleich am Anfang geben, damit es auch jeder hört. Hier geht es um eine fachliche Beschreibung und nicht um eine technische Beschreibung.
Ja, ein sehr wichtiger Punkt. Ich finde es auch gut, dass du direkt sagst, aus Sicht des Endnutzers oder Endanwenders, wie du es gerade gesagt hast, weil das ist nämlich der entscheidende Punkt dabei, dass du halt den Fokus auf den Endanwender legst und es aus also durch seine Brille auf das Produkt guckst, wie man so schön sagt. Und auch diese Beschreibung dahinter sorgt ja dafür, oder? Das Ziel ist ja wirklich Klarheit zu schaffen, was am Ende wirklich programmiert werden muss und.
Oder soll und vor allem warum. Deswegen haben wir ja quasi schon gesagt, warum sind sie so wichtig, weil also es soll darin definiert werden, warum machen wir das Ganze hier eigentlich, und das, da gibt es ja nichts Besseres, als es aus Sicht des Endanwenders zu betrachten, genau weil da muss das warum ja drin sein. Ich finde, im Ziel ist es auch immer gut, wenn man sich vor Augen hält, dass man sagt, OK, welcher Wert. Oder welcher Value wird mit
dieser User Story geschaffen? Also wenn du am Ende dieser User Story, wenn du sie dir durchgelesen hast, dir denkst, weiß nicht, am Ende passiert jetzt irgendwie, aber eigentlich nicht wirklich was oder du kannst das eigentlich irgendwie gar nicht richtig verwenden, das was da beschrieben ist. Also du hast halt diesen Nutzen für den User am Ende nicht, dann ist es eigentlich nicht wirklich das also das Ziel wurde da nicht richtig erfüllt mit dieser User Story.
Deswegen in dieses, dieses Klarheit schaffen. Worum geht es, welchen, welcher wert wird geschaffen und warum? Wie du meintest wird dieser Wert geschaffen, ne ja genau, und warum sollte man jetzt nicht einfach Anforderungen auflisten, kann ja jetzt auch so die erste Frage sein. Ja ist ja cool das aus Sicht des Users zu betrachten aber so gerade in der Vergangenheit in in der alten Welt, da wurden
einfach Anforderungen definiert. Und wir haben ja, wie gesagt, einen wichtigen Punkt dabei schon genannt, dass halt die Kundenzentrierung sehr entscheidend ist. Stell den Kunden in den Fokus um einfach auch ne bessere Entwicklung zu ermöglichen am Ende. Ich finde aus persönlicher Sicht und ich denke da stimmst du mir auch zu user Stories sind auch einfach viel leichter zu verstehen, wenn ich so an meine frühere Zeit denke, so in meinen ersten Berufsjahren habe ich auch oft nach.
Ist ja auch ne Weile schon her. Nach strikten Anforderungen entwickelt und wenn du aber so ne Anforderung erstmal 5000 mal durchlesen musst um überhaupt zu verstehen wo in welche Richtung das geht, wie das überhaupt in das Produkt einzahlt und am Ende trotzdem noch super viel Variabilität da drin ist, weil es einfach gar nicht ausführlich genug beschrieben ist, dann schafft das kein gutes Verständnis und vor allem schafft es kein gutes Verständnis und das ist n
wichtiger Punkt über das gesamte Team. Ja, also du liest es dir jetzt mehrfach durch. Du versuchst das Verständnis aufzubauen und bist vielleicht in der Lage, das umsetzen zu können. Wenn jetzt aber n Kollege von dir das übernehmen soll, muss er sich genauso wieder reinfressen gedanklich. Ja. Also es ist halt schwierig, das auch quasi aufs Team denn so auszubreiten aus meiner Sicht.
Und wenn ich jetzt ne gut geschriebene User Story hab, die nicht technisch ist, weil du das ja wirklich explizit am Anfang schon erwähnt hast, ja. Ist es halt viel schneller zu verstehen. Was soll jetzt eigentlich gemacht werden oder was ist das Ziel, wie du so schön gesagt hast. Ja ja das find ich, kannst du tausendmal schneller erreichen mit User Stories. Ich find das, was du gerade beschrieben hast.
Ich kenn das. Das ist auch so n so ne richtige absolute Bad Practice ist so was ich auf jeden Fall auch schon erlebt hab. Es wird eine user Story geschrieben, wo eigentlich nur eine E Mail rein kopiert wird, wo jemand irgendwie mal so einen vagen Wunsch geäußert hat über irgendwas und dann wird diese Mail einfach in diese user Story rein kopiert und dann wird gesagt so okay und jetzt go und
du denkst dir so okay warte mal. Also es gibt keinerlei Absprachen irgendwie über ein Feature, das ist einfach jetzt eine Art Mail in eine User Story gequetscht und.
Das ist alles andere als klar, weil klar, jeder hat vielleicht eine unterschiedliche Interpretation, eine unterschiedliche Interpretationsspielraum, den man irgendwo reingeben kann, aber genau deshalb ist es ja so wichtig, möglichst diesen Interpretationsspielraum einzuschränken, um zu sagen, es ist nicht so, dass zum Beispiel Person a sich das durchliest und irgendwie eine Vorstellung hat, Person B sich das vorliest, auch irgendeine Vorstellung davon hat
und beide Vorstellungen komplett unterschiedlich sind.
Weil dann hast du irgendwann das den Effekt, dass zum Beispiel, also dass es nicht egal ist, welcher welches Teammember sozusagen sich diesen diese user Story schnappt und bearbeitet, sondern es ist hat n unglaublichen Impact, weil so viel Interpretationsspielraum da ist, dass man einfach entweder dies, das oder jenes machen könnte und am Ende kommst du ja an den Punkt, dass du dann das irgendwann abgeschlossen hast und n Teammitglied dir sagt, so war das doch gar nicht gemeint,
oder? Und dann kommt sozusagen der Stakeholder, der das sozusagen ne vorgeschlagen hat oder eingebracht hat. Diese User Story und sich denkt, na ja, also nee, so nicht, aber so wie du sagst auch nicht.
Also das find ich jetzt blöd, also weißt du, das ist ja, deswegen ist es halt wichtig auch ne gewisse Struktur in diese User Stories reinzubringen und auch noch mal zu dem Punkt technisch ne. Ich habe das auch schon erlebt, dass zum Beispiel User Stories versucht wurde, das was gemacht werden soll, sehr, sehr technisch zu beschreiben und ich finde und das ich finde, ich finde das ist so ein unglaublich wichtiger Punkt, der auch nicht in die User Story reingehört,
weil angenommen du sagst zum Beispiel okay ich habe eine Anwendung und möchte jetzt eine Authentication da reinpacken, also irgendwie du hast ein User Management System und möchtest
sagen. User X kann sich jetzt anmelden, ne als Beispiel, dann willst du ja sagen OK ne user Story könnte ich verpack das jetzt einfach nur mal ganz wörtlich mit einem großen Interpretationsspielraum, aber dass du sagst du hast eine Anmeldemaske und wenn du in diese Anmeldemaske deinen Usernamen und dein Passwort eingibst und es stimmt, dann kommst du ins System rein, wenn es nicht stimmt kriegst du eine
Nachricht, stimmt nicht. So, das ist ja ne sehr sehr fachliche Beschreibung. Davon sollte man natürlich noch in einer gewissen Struktur abbilden, das ganze aber um es zu verstehen, weißt du ja dann in diesem Moment, OK, alles cool, das ist erstmal. Du weißt was passieren soll, aber was genau wie sozusagen technisch under the Hood diese Authentifizierung funktioniert, was da für ne.
Für eine Kommunikation stattfindet, wie das gespeichert wird, wie das verschlüsselt wird und so weiter das sind ja wichtige Punkte, die überhaupt nichts darin zu tun haben. Aber du könntest ja rein theoretisch diese user Story so schreiben, dass du sagst, verwende bitte authentifizierungsverfahren XY, das und das und dann denke ich mir so, das kommt ja normalerweise, kommt ja so eine user Story nicht von einem Entwickler oder einer Entwicklerin, also. Kann diese Person ja gar nicht
diese Entscheidung treffen. Darüber also diese Expertise einbringen, weil das ist ja Part des Entwicklerteams ne und deswegen lange Rede kurzer Sinn, fachliche Anforderungen kommen in die User Story und die technischen Details werden dann vom Entwicklerteam geklärt. Ja, macht ja auch Sinn. Also wie gesagt, wir haben ja gesagt, der Fokus soll auf die Sicht des Endanwenders sein und der Endanwender. Dem ist reichlich egal, was für n Authentifizierungsverfahren
dahinter steht. Er möchte in deiner Maske seine Login Daten eingeben und dann zu seinem Dashboard bei beispielsweise weitergeleitet werden, weil er geht ja davon aus wenn ich die richtigen Daten eingebe komm ich da auch hin ne und das ist ja so wirklich die User Story da am Ende und ich find auch wichtig, dass du sagst es muss so n so n festen Aufbau geben und da gibt es auch verschiedene Schreibweisen.
Viele, also einige, haben sich davon auch wirklich so gut durchgesetzt, dass man sagen kann, das ist schon Standard, irgendwo, jedenfalls aus meiner Sicht, so verwende ich es gerne, beispielsweise, dass man immer erstmal sagt, ich als User oder meine Benutzerrolle ne, also du kannst ja auch mehrere Rollen haben, es kann ja mehrere Endanwender geben. So ne Art aber zum Beispiel. Genauso personas, dass du sagen kannst, mein ich als User jetzt als wirklich Endanwender.
Ich möchte, geht ja auch. Ja genau das wär jetzt so ne andere Rolle, aber jetzt gehen wir jetzt noch mal von dem User aus, dann sagst du halt ich als User möchte quasi mich einloggen auf dieser Seite um dann das ist so der Nutzen dann am Ende warum will ich das machen um auf mein persönliches Dashboard zu kommen? Dann kannst du sagen, damit habe
ich abgedeckt. Wer also benutzerrolle User, was ist mein Ziel ne also ich möchte mit meinen Daten mich einloggen, das ist mein Ziel und warum will ich das machen, das ist halt das warum, damit ich in meinen persönlichen Bereich komme so und das ist erstmal so ne grundlegende Formulierungsart wenn die sich etabliert auch in einem Team kannst du sowas unfassbar schnell lesen und du brauchst nicht viele Sätze, du brauchst halt keinen riesen Text.
Ne. Genau, ich mein das, das kann man noch sehr gut erweitern, so wie wir es auch machen. Da würd ich aber später drauf noch mal eingehen. Also das wär jetzt so quasi die User Story als Szenario beschrieben, worum geht es, warum möchte der User das machen ich. Find das auch gut, dass du sagst, OK ne, also diese diese, diese diese als diese Rolle einnehmen. Ne ja, also aus Sicht dieser Story. Und dann noch das, was du meintest, dass ich auf mein Dashboard komme.
Das ist ja im Endeffekt der dieser Value, dieser wert, was ich meinte, ne das am Anfang war wichtig, genau und das. Warum denn einfach? Genau. Warum will ich das überhaupt genau? Und damit hast du ja schon mal ganz klar abgesteckt und ich finde diese diese Art, dass du sagst, ich als User dieser Anwendung oder ich als Admin dieser Anwendung oder was auch immer ne. Damit kannst du dich ja, wenn du dann irgendwie irgendwann muss man diese user Story ja auch
abnehmen. Das heißt, die User Story wird erstellt, die User Story geht ans Developer Developer Team, dann wird sie bearbeitet und irgendwer muss ja im Normalfall die Person, die das sozusagen gestellt hat beziehungsweise als Proxy sozusagen der Po diese User Story irgendwie abnehmen und sagen okay passt es oder passt das nicht und genau an der Stelle ist es ja dann auch gut sich. Einmal, wenn du aus der entwickelnden Sicht guckst und sagst okay was, was soll hier eigentlich passieren?
Okay ich versetze mich jetzt mal in die Lage, ich bin der User, so weißt du und so kannst du das dann lesen und dann halt auch das Ganze dann sozusagen betrachten, bearbeiten und genauso kannst du auch irgendwann sagen okay ich bin jetzt der Po und möchte das jetzt zum Beispiel abnehmen und sagen ist diese user Story richtig umgesetzt, dann kannst
du ja genauso wieder sagen okay. Ich gucke jetzt mal durch und sage jetzt mal, ich bin jetzt der User und möchte mich jetzt zum Beispiel anmelden, um auf mein Dashboard zu kommen.
So und wenn ich jetzt aber sage, ich gebe jetzt meinen Usernamen und mein Passwort ein und man kommt dann und du weißt, du hast dein richtiges Passwort eingegeben und du kommst nicht dahin, dann kannst du halt nur sagen okay sorry, die User Story ist nicht richtig umgesetzt, wenn es aber funktioniert und du aber vielleicht bei einem falschen Passwort oder falschen Usernamen falsche Kombination. Irgendwie eine Nachricht
bekommst. Sorry, aber Username oder Passwort ist falsch, dann weißt du OK, einerseits entweder ich komme rein mit den richtigen Credentials oder mit den Falschen komme ich nicht rein, das heißt du kannst dich gut reinversetzen, diese Story abnehmen und gucken ob der Wert auch wirklich geschaffen wurde und das ist dann halt perfekt und ich finde da kommen wir auch an einen ganz interessanten Punkt, weil wie also wie kann man denn jetzt zum Beispiel
gucken, dass man eben. Dass diese User Story auch umgesetzt wurde und da gibt es ja so die ich sag mal diesen diesen Begriff akzeptanzkriterien so ne ja, also im Prinzip akzeptanzkriterien sind dafür da um klare Bedingungen zu schaffen, wann denn diese Story fertig ist, also wann es ist ja als Entwickler wichtig zu wissen wann. Bin ich mit der Story fertig?
Wann habe ich meine Arbeit getan, was muss alles umgesetzt werden und sobald Spielraum in der Beschreibung kommt, reinkommt, also dass jeder ein anderes Verständnis davon hat, dann können so eine Stories halt in so unendliche gehen gefühlt und manchmal tun sie es auch, also weil ja nee, ich hätte jetzt gedacht, das und das muss da rein, ja okay dann machen wir das noch rein ja aber ich verstehe das so und so, wir müssten das und das noch machen. Ja, OK, dann bauen wir das auch
noch ein. So und dann ist es so ne Never ending Story und da kommen halt akzeptanzkriterien. Ins Spiel User Story. Ja ha, ha ha. Und da kommen halt diese Kriterien ins Spiel, weil sie helfen ganz klar zu definieren, was muss getan werden, damit dieser Value geschaffen wird am Ende und. Du hast es auch jetzt schon angerissen.
Es ist halt auch super hilfreich um das Ganze zu Reviewen am Ende, also quasi wenn einer das abnimmt, diese Story, dieses Ticket, dann hat er auch klare Kriterien, was muss ich denn machen um zu sehen ob alles funktioniert? Nehmen wir noch mal dein Beispiel mit dem Einloggen. Ja okay ich nehme meine Credentials so, ich gebe das da ein Username Passwort was war denn username fabi 1234 ne?
Passwort 1234 drück Login, drück Login ah ja hier mein persönlicher Bereich funktioniert so und ich bin sogar mit meinem User drin. Ich hab nicht irgendeinen anderen gerade weißt du funktioniert alles so ausloggen ja jetzt mach ich fabi 1234 und gib ein anderes Passwort ein Ah ja geht nicht, dann war mein richtiges Passwort fabi 1324 geht auch nicht ja gut okay. Das waren so die Kriterien.
Funktioniert Ticket abgeschlossen, also user Story erfüllt genau und das kann man ja auch als nicht technische Person, sogar als nicht, nicht mal als Person, die super vertraut mit allem ist. Also die wirklich jedes Detail kennt, das sind ja so Kriterien, da kannst du sagen Ey auch Person xy, magst du das vielleicht mal testen?
Genau, weil es ist ja eine wie eine Art Fahrplan, nach der du dich durchhangeln kannst, um zu gucken, ob der Wert der in dieser User Story beschrieben ist, auch wirklich vorhanden ist. Nach der Implementierung genau, und das ist halt einfach unglaublich wertvoll und ich finde es unglaublich gut, dass du sagst, es braucht kein, wenn du eine User Story gut schreibst, braucht es kein technisches Verständnis um zu verifizieren, dass es funktioniert, dass der Wert geschaffen wurde und.
Ja, genau. Das heißt, du hast diese Akzeptanzkriterien. Du hast vorher den den den Rahmen geschaffen, mit der anderen Struktur, also ich als Rolle, dann hast du diese 2 Sachen und das ist in meinen Augen der Frame, den ich mit einer User Story schaffen möchte, das heißt ich ich definiere aus welcher Sicht möchte ich was machen und warum und dann definiere ich mit Hilfe von Akzeptanzkriterien wie das Ganze.
Als erfüllt gilt sozusagen genau also bei Akzeptanzkriterien gibt es ja tatsächlich mehrere Möglichkeiten, das irgendwie darzulegen. Also du kannst ja zum Beispiel sowas machen wie Definition of dann beziehungsweise so ne Art Liste, wo du so tasklisten genau sowas in die Richtung und
verschiedenste Möglichkeiten. Die man da irgendwie nutzen kann und eine, die wir ja ganz besonders gerne nutzen, ist die sogenannte gerkin Schreibweise. Da geht es ja wirklich darum um um also kurz gesagt, du hast so ne Art given, so ne Art wenn und so ne Art, wenn ne Given ist im Endeffekt der Ausgangszustand ein einer Story oder der Kontext in dem wir uns gerade bewegen, das bedeutet also in dem Beispiel was wir vorhin hatten, dass man sagt, OK, ich als User bin sozusagen nicht
authentifiziert auf meiner Seite.
Irgendwie so was als Beispiel so, das ist erstmal so der Frame so das ist das Given. Also erstmal du weißt ja ich als User und dann brauchst du nicht mehr sagen, ich als User kannst du noch sagen given ich bin auf der Startseite so was als Beispiel, dann gehst du weiter und sagst okay wenn das ist dann das auslösende Ereignis oder diese Aktion die getätigt wird, das ist im Endeffekt ich gebe mein also wenn ich meine mein Username und Passwort korrekt eingebe.
So und dann, wenn das ist sozusagen dann das erwartende Ereignis oder das Verhalten, also wenn ich quasi auf den Knopf sign in drücke, dann erwarte ich halt im Endeffekt auch, dass ich eingeloggt bin auf meinem Dashboard, dass ich mein Dashboard sehe, also einmal noch mal kurz zusammengefasst given ich bin auf der Startseite, wenn ich meinen Username und Passwort korrekt eingebe und auf sign in drücke
dann. Dann also dann bin ich auf meinem Dashboard in meinem user Bereich, was auch immer und das ist kann man sich natürlich hinstellen und sagen okay das ist jetzt ein Akzeptanzkriterium es hindert eigentlich daran noch ein zweites Akzeptanzkriterium zu nehmen und zu sagen okay wenn ich auf der Startseite bin und ich gebe zum Beispiel meinen richtigen Usernamen ein, aber ein falsches Passwort und ich drücke auf sign in, dann kriege ich eine Fehlermeldung genauso
andersrum. Wenn ich halt eben dann meinen falschen Username und richtiges Passwort theoretisch eingebe. Ne, also man kann das auch in 3 User, also in 3
akzeptanzkriterien gliedern. Du hast vielleicht das gleiche Given, aber es macht die Sache nicht nicht schlimm an der Sache, also an dieser Stelle ne. Also ich würde jetzt zum Beispiel nicht mich hinstellen und sagen, ja, du hast doch dreimal das gleiche Given, also kannst du das optimieren, so das sind 3 Akzeptanzkriterien schreibst sie genauso runter und dann kann man das auch. Sage ich jetzt mal autark
abarbeiten. Ja, und wenn du halt immer die gleiche Schreibweise verwendest, wirst du über die Erfahrung hinweg also umso länger du damit arbeitest, sie auch immer schneller lesen und verstehen können, weil du halt genau weißt, in der Zeile steht jetzt die Bedingungen sozusagen oder die, nee sage ich mal die Grundlage dann, was mache ich und was erwarte ich dann sozusagen. Also es ist halt genau das, was du beschrieben hast.
Und das ganze, du hast es in deinen Sätzen eingebaut, ist aber von von der Schreibweise her auch völlig in Ordnung, dass Du mit End arbeitest um einfach auch Verknüpfung zu schaffen
beispielsweise. Given der Teil. Ich bin auf der Startseite und bin auch ein registrierter Nutzer, könnte man dann zum Beispiel machen, weil du hast ja theoretisch auch das Akzeptanzkriterium jemand der nicht registriert ist, sollte nicht willkürlich irgendwas eingeben können um sich einzuloggen und auf irgendeinen Dashboard zu kommen, beispielsweise nur mal jetzt als Beispiel, dass du Verknüpfung schaffen kannst, was auch gang
und gäbe ist. Genau du musst halt gucken, dass es nicht ausartet, das ist halt sag ich mal given. Bedingung A und Bedingung B und Bedingung C und Bedingung D und so weiter bis z Ich warte kurz, da kann dir das gedanklich weitermachen, weil das spricht schon wieder, dafür. Ist das wirklich ein Akzeptanzkriterium oder was für ne Abhängigkeiten sind da gerade bitte drin? Das lädt schon wieder ein das Ganze noch mal zu durchdenken, aber so 12 NS kannst du da machen, warum nicht?
Das liest sich ja trotzdem noch schnell und schafft halt auch diesen Rahmen für diese Akzeptanz. Um das schnell zu verstehen. Im Endeffekt greift ja da so eine goldene Regel, dass du sagst, du brauchst genug Details um halt eben mit der Story sozusagen zu starten, aber nicht zu viel, dass es total überladen ist, dass du dir eigentlich wieder eine Art Pseudocode aufbaust, wo du dann ewige
Verschachtelung drin hast. Und das ist n sehr wichtiger Punkt, dass du sagen kannst, es sind genug Details um zu starten, weil wir gehen jetzt mal davon aus, wir sind halt in einem agilen in sag ich mal in einem agilen Umfeld und da gibt es ja auch zum Beispiel nach Scrum Termine wie Refinements, das heißt, sollte da vielleicht in Zukunft bei diesem Ticket
doch noch was unklar sein? Genau dafür sind ja auch Refinements da am Ende ne. Also das Ziel ist ja nicht zu sagen, ich schreib das Ticket so voll, da ist kein. Kein Platz mehr, kein Finger breit, mehr Luft an Spielraum sozusagen, sondern es ist so gesehen klar, was gemacht werden muss. Und es ist aber auch wahrscheinlich, dass im Laufe der Arbeit man sich denkt, so,
ja, warte mal. Aber den Fall haben wir jetzt gar nicht berücksichtigt, und das ist völlig OK, weil dafür gibt es auch refinance, dann gehst du halt noch mal ins Team oder in Huddle, also du musst, musst ja auch nicht auf n refinance Termin warten, aber du kannst es ja einfach nachträglich diskutieren und das Ticket auch noch anpassen. Definitiv. So kannst du auch eine Akzeptanzkriterium hinzufügen. Alles ganz Stress.
Und was auf jeden Fall zum Beispiel, ich finde dein Beispiel gerade ganz cool, dass du gesagt hast, ich als registrierter Nutzer, zum Beispiel, dass du dann halt sozusagen diesen Frame schaffst und sagst, du kannst dich logischerweise nur anmelden, wenn du auch registriert bist. Und wenn man jetzt vielleicht auf die Idee kommt und sagt, Na gut, dann erweitere ich diese Story, die da heißt, user, was
weiß ich. Sign in and sign sign oder so ne. Also dass du dich registrierst, also die sozusagen Registrierungen und nennen wir es mal User Management und du willst jetzt eine Story schreiben wo du drin sagst so wenn ich nicht authentifiziert bin und dann muss ich quasi meine E Mail oder meinen Usernamen und mein Passwort eingeben und bin dann registriert und wenn ich aber registriert bin, dann kann ich quasi mit meinem kann ich meinen Usernamen und mein Passwort
eingeben und dann komme ich rein so ja. Wenn man jetzt auf die Idee kommt und sagt, gut klar, dann erweitere ich meine Akzeptanz, Kriterien, dann gibt es an der Stelle halt eben auch wie gesagt den Kontext, weil an dieser Stelle kann man sich hinstellen und sagen, warte mal, wir, wir schaffen ja hier 2 Werte, also 2 values an dieser Stelle einmal die Registrierung und einmal den Login, das sind ja 2 einzelne Dinge, die unabhängig voneinander.
Funktionieren können. Also können Sie auch unabhängig in 2 verschiedene User Stories rein. Ganz genau. So, und das ist halt auch ein wichtiger Punkt, den man an der Stelle berücksichtigen sollte, weil wie gesagt, man sollte darauf achten bei einer User Story möglichst kleine Pakete zu schnüren, die in sich funktionieren. Die halt diesen Wert schaffen, aber trotzdem irgendwo autark abhandelbar sind. Finde ich ist ein super Beispiel oder?
Beziehungsweise ein sehr sehr guter Hinweis an der Stelle eine Sache noch bevor wir mal so quasi die Formalitäten abschließen. Wir haben ja gesagt in so einer User Story sollte das ganze nicht technisch betrachtet werden, sondern aus fachlicher Sicht absolut richtig.
Ich finde Ausnahmen bestätigen die Regel und nur deswegen noch mal ganz kurz als Anmerkung. Wenn man jetzt die User Story so aufbaut, wie wir es gerade zum Beispiel vorschlagen oder was auch so gängig ist, wir auch verwenden, dass ich sage, ich baue mir dieses Szenario auf mit dieser Nutzerrolle und was möchte er warum machen der Nutzer oder die Nutzerin dann die Akzeptanzkriterien, dann kann ich, wenn es wirklich notwendig ist und nicht standardmäßig, deswegen
optional. Gibt es Anmerkungen zu dieser Story? Irgendwas Wichtiges, zum Beispiel auch UIUX, mäßiges oder irgendeine technische Abhängigkeit? Doch also also doch ne technische Abhängigkeit so rum, dann kann ich unten natürlich noch optional Anmerkungen hinschreiben, auch von von Entwickler zu Entwickler beispielsweise, das ist vollkommen legitim, sollte aber halt nicht diese goldene Regel. Du hast so schön goldene Regel genannt.
Super, wenn ich jetzt auch verletzen, dass ich die komplett überlade, dass ich da einfach alles reinknalle und noch e Mails in Anhang packe und Diskussion und n Chatverlauf noch rein weißt du das sollte es halt nicht verletzen.
Wenn es aber wirklich aus Erfahrung oder aus der Sicht eines Entwicklers beispielsweise sehr wichtig ist, das da anzumerken, dann kann ich da unten natürlich sowas auch reinschreiben, wenn es dem Entwickler, der das später oder Entwicklerin die das später bearbeitet hilft. Um nicht vielleicht in eine Falle zu tappen, in der Entwicklung oder so. Dann lieber reinschreiben
deswegen. Also es gibt für mich gedanklich immer noch so einen optionalen Blog, den ich nicht oft verwende, aber es kann sein, dass es angebracht. Ist also ich finde ein kleines Beispiel was was mir jetzt so spontan einfällt wäre, man entwickelt irgendwas und es werden vielleicht innerhalb dieser user Stories vielleicht du weißt eigentlich, das ist eine Sache, die.
Zwar rein theoretisch sehr technisch ist, aber du weißt jetzt schon, du kommst nicht drum herum, dass zum Beispiel irgendwie n file generiert wird oder irgendwas, was da hinterher irgendwie raus ploppt und du sagst so OK, es wäre nicht cool, wenn das jetzt beispielsweise irgendwie im Git repository landet, also kann man in die Note zum Beispiel schreiben, ja denkt man dran, dass man da dieses File oder dieses, was da irgendwie generiert wird, dass das auf die Git ignore kommt,
weil ansonsten kommen wir das permanent immer mit rein, so ne also. Weiß nicht, vielleicht gibt es auch noch bessere Beispiele, dass es mir spontan geht, aber das ist genau so eine Kleinigkeit, was ja technisch ist. Das ist ja dem Endanwender egal, wie das Repository verwaltet ist, aber das kann den
Entwicklern halt helfen. Es kann halt auch sein, dass du sagst, Hey, das ist das die und die User Story klingt erstmal trivial, aber mir ist jetzt schon klar, dass wir in irgendeiner Schnittstelle ein Breaking Change haben, das heißt, dass wirklich Sachen. Migriert werden müssen oder whatever wenn du sowas reinschreibst, dass du einfach schon so ne so ne so ne awareness schaffst, sag ich mal ne, dass alles schon mal darauf, also dass allen bewusst ist.
Ey, das wird hier an der Stelle, müssen wir da und da aufpassen, dann ist das n guter Hinweis auch in so einer Story. Aber ich mein oder ein? Ticket genau.
Also wenn man jetzt zum Beispiel gerade zuhört und sich denkt, ja, Moment, aber warte mal, also wir reden davon, dass jetzt zum Beispiel Entwicklerinnen und Entwicklerin nicht diese Story schreibt, weil das nicht die Aufgabe von Entwickler oder Entwicklerin ist, sondern zum Beispiel Aufgabe von PO, diese Stories zu schreiben, dann könnte man sich ja fragen, wie soll jetzt der PO eventuell irgendwie diese technischen, das technische Wissen haben, vielleicht hat er sie, hat er es
aber vielleicht auch nicht. An der Stelle würde ich jetzt noch mal kurz anmerken, wie du meintest, man ist im Refinement, man redet darüber, man definiert dieses Ticket ja und sagt Okay Pass auf, darüber sprechen wir, wir schaffen ein einheitliches Verständnis über dieses Ticket, dann wird das auch noch
geschätzt. Thema schätzen hatten wir eine Folge, hört da gerne mal rein liebe zürerin lieber Zürer an dieser Stelle. Kann man ja zum Beispiel an den Punkt kommen, dass man sagt, ja ne Breaking Changes, da müssen wir auf jeden Fall drauf achten und dann kann man ja zusammen in diesem Termin, in diesem, in dieser Zusammenkunft einfach mal kurz Notes drunter schreiben oder vielleicht auch n Kommentar drunter packen, je nachdem wie das System mit dem man arbeitet
aufgebaut ist. Aber das kann man ja an der Stelle machen, ne? Ja, sehr guter Hinweis, weil genau das ist der der Punkt, wo man denn sagen kann, OK nee, das definieren wir da jetzt noch mit rein oder hinterlegen das da. Weil es wirklich auch mehr Wert schafft, um es schneller entwickeln zu können oder Fehler zu vermeiden. Ganz klar ja. Guter Hinweis, ganz klar ist so n refinement Thema sehr oft oder auch aus eigener Erfahrung kommt sowas denn eher in n Refinement dazu?
Ja, ja, jetzt. Haben wir ja viel Formales besprochen, wie wir sie aufbauen würden, was auch so gängig ist. Also die haben uns das ja nicht selbst ausgedacht, sondern. Es gibt dieses Format, sage ich mal, user Stories so zu schreiben und wir haben es ausprobiert.
Wir verwenden es und für Gute, Wir haben es für gute Befunde und nutzen es deswegen auch, aber lass uns noch mal so ein bisschen differenzieren, was wirklich jetzt also zu Take Home message mäßig was so Best practices sind und was eine gute User Story ist. Und da würde ich noch mal. Sehr allgemein anfangen bevor wir so zu richtig spezifischen Do's and Don's kommen okay dann möchte ich dann warte, da möchte ich noch mal den ersten direkt bringen.
User Stories haben Fachlichkeiten beschrieben und keine technischen Details. Ja das ganz oben ganz oben, weil das ist mit Schrift, das ist mir wirklich wichtig, weil der Herzensangst, da habe ich auf jeden Fall auch schon einige Erfahrungen gemacht, dass das nicht so gehandhabt wird und dann? Kommst du auf einmal in Diskussionen mit Leuten, die technisch vielleicht wirklich gar nichts damit zu tun haben beziehungsweise aber auch wirklich auch nicht die Verantwortung technisch dafür
übernehmen müssen? Und dann denke ich mir mal, wieso sollte jemand, der nicht die Verantwortung über die technische Seite hat, auf einmal vorgeben wollen, wie es technisch umzusetzen ist? So, da muss man halt auch wirklich die Verantwortlichkeiten an der Stelle lassen, wo sie sind und das Entwicklerteam wurde dafür eingestellt um die Software zu entwickeln, also Expertise. Technisch softwareentwicklungsteam.
Ja, sehr gut, wirklich. Wie gesagt in Leuchtschrift oben, das ist, das scheint ja sehr wichtig zu sein, ist es auch wirklich und da habe ich auch sehr schlechte Erfahrungen mit gemacht, gerade so aus der Zeit der typischen Anforderungen von früher so Lastenhefte, aber die Punkte, die wir also gefühlt
eigentlich schon. Meine ich alle, die wir jetzt angesprochen haben, kann man für alle Theorie Fans jetzt unter den Zuhörerinnen und Zuhörern kann man in ein Modell kippen oder wurde auch mal als Modell definiert. So typisch wieder ein Wort mit Abkürzung was du verwenden
kannst um dir das zu merken. So eine Eselsbrücke nennt man das Glaube ich Eselsbrücke und zwar das Invest Schema oder Modell so Invest. Da haben wir am Anfang ein I. Und das steht für Independent, und das ist genau der Punkt, den Du am Anfang oder relativ in der Mitte ist. Schon n bisschen her jetzt genannt hattest.
Und zwar trenn doch Registrierung von einloggen, das sind doch 2 User Stories und das hast du ja auch gut beschrieben und genau das ist es auch, was mit unter Independent steht. Sie können einzeln stehend und alleine umgesetzt werden, also sie sind in sich beschrieben und autark und man kann sich diese Story nehmen und sie so wie sie ist umsetzen. Ja, und das ist n sehr wichtiger Punkt.
Wenn du nämlich das nicht schaffst und du hast Dependency zwischen diesen ganzen User Stories, dann wird es richtig wild. Welche wirst du als erstes abarbeiten? Du fängst eine an erwarte hier komm ich nicht weiter, ich muss ja jetzt erstmal die andere user Story machen und dann baust du dir so ein Netz an Verwirrtheit auf. Man muss halt dazu, man muss halt dazu sagen, also. Unabhängig umzusetzen sind beide definitiv und darum geht es ja vor allem.
Das heißt, du hast du Blockst mit der einen Story nicht die Entwicklung der anderen Story wichtiger Punkt, klar kann man an der Stelle sagen, wenn du die Login Story abgeschlossen hättest und jetzt zum Beispiel unabhängig Po rein fachlich überprüfen möchte ob man sich anmelden kann, dann geht das natürlich nur mit der Registrierung, also mit vorheriger Registrierung. Ne rein theoretisch, das heißt die Abnahme kann sonst erstmal nicht erfolgen, aber auch da
kann man sich natürlich behilflich sein, ne und in zum Beispiel einer Test Stage sagen oder einer Development Stage wie man sie nennen mag, dass man halt irgendwie auch schon Test User anlegt wo man sagt Login funktioniert damit ne. Also guter guter Einwand, ich wollte es nur mal sagen, weil man kann sich natürlich sofort hinstellen und sagen ja, aber Login geht ohne Registrierung nicht. Ist ja auch, also. Man kann ja auch das nicht immer
vermeiden. Es geht ja jetzt darum, was sind gute User Stories, also was ist mein Ziel, wie ich Sie aufsetzen möchte und natürlich hast du auch blocker, dass zum Beispiel User Story B niemals ohne User Story a funktionieren kann beim Endanwender und da kann man sich dann halt mit geschaffenen Umgebungen quasi helfen, wie du es gerade so schön gesagt hast, um doch das autark entwickeln zu können, ist nicht so, dass es nicht geht, genau. So genau dann.
Was haben wir als Nächstes das n ne go to go, das ist ein komisches Wort, ja ich bin da, weil es gibt so Wörter da da na ja, aber es war halbwegs richtig und zwar Details sind klärbar aber nicht in Stein gemeißelt und das ist auch n Punkt den wir angesprochen haben, das ist ein lebendes.
Wie soll ich sagen, also eine User Story lebt, sie entwickelt sich weiter, sie kann auch mal umdefiniert werden, es gibt Refinance, das heißt es ist nicht in Stein gemeißelt wo wir wieder Thema Lastenheft sind oder so ey hier das machst du jetzt und in 3 Monaten komm ich wieder und dann läuft dies alles klar weißt du also das ist halt auch n wichtiger Punkt den man einfach von vom Mindset her mit sich tragen sollte ja vor allem was ich auch oft erlebt habe, in diesem Punkt ist, dass du
natürlich ne. Idee hast die von einem Stakeholder kommt und dann heißt es ich würde gerne oder in dieser Anwendung wollen wir gerne das und das haben okay wie wollt ihr das haben so und so okay du fängst anders zu entwickeln und merkst wir haben hier ein Edge Case das funktioniert nicht ganz hundertprozentig so wir müssen vielleicht einen Kompromiss machen und dann ist genau der Punkt. Es ist nicht in Stein gemeißelt, sondern man muss natürlich dann noch mal, vielleicht unter
Umständen, in den Austausch gehen. Im optimalen Fall logischerweise beim Refinement, bei der Besprechung dabei, dass man das so schon auf dem Schirm hat, aber Ausnahme steht ihnen ja, wie gesagt, die Regeln.
Es kann sein, dass du halt mal an den Punkt kommst, wo du sagst, ich hab schon angefangen zu entwickeln und jetzt fällt mir das erst auf, kommt ab und an mal vor und da ist es natürlich sehr wichtig, dass es eben nicht in Stein gemeißelt ist, sondern dass man sagen kann, OK, wir haben Spielraum. Weil ansonsten wir bringen die sonst einfach ja absolut, dann haben wir. INV also valuable. Das hatten wir auch schon mehrfach.
Genau das muss halt n Mehrwert geben, das ist das ganz große Ziel dahinter, da braucht man nichts weiter zu sagen eigentlich. Dieser sogenannte User. Value genau das E für Astonable das ist im Prinzip, dass der Aufwand auch Schätzbar ist. Und da kommen auch die.
Genau diese Schreibweise, für mich persönlich immer ins Spiel, wenn ich diese givenwhere than Schreibweise hab, hab ich schon viel klareres Verständnis über die Akzeptanzkriterien und wie am Ende dieses Feature in der Software aussehen soll, inklusive des Szenarios wer möchte was machen und warum und das hilft um auch so Aufwände einfach besser schätzen zu können um überhaupt erstmal n. Gefühl für diese User Story zu
kriegen. Und deswegen hilft diese Schreibweise quasi, um eine gute User Story und diesem Modell gerecht zu werden. Quasi eine gute User Story zu
schreiben. Also ich finde, dass ich so von kurz, kurz und knapp der Ablauf, es gibt diese User Story mit den Akzeptanzkriterien und die werden kurz besprochen, jeder Entwickler, jede Entwicklerin hört das es fängt an zu rattern, man geht gedanklich in den Code, wie setzt sich es um, was muss ich machen, welche Sachen fasse ich an, das geht eigentlich bei mir immer sofort los und dann ist kriegst du eigentlich
relativ gut so zusammengefasst. OK, jetzt kann ich das ungefähr schätzen, dass du halt auch irgendwie, dass du so weit an diesem Thema dran bist, dass du auch damit arbeiten kannst und sagen kannst, ja, ich glaube ungefähr so Schätzung XY ne, also was nicht schätzbar wäre wäre zu sagen ich möchte ne Anwendung für die das und das macht was schätzt du? Denke. So, ja was soll ich da? Schätzen und gefühlt kriegt man manchmal so ne Titel.
Ja, also wohlgemerkt an der Stelle, dass es nicht um zeitliche Schätzung, sondern Komplexität geht. Also da helfen halt diese Akzeptanzkriterien, um überhaupt mal die Komplexität dieser User Story abschätzen zu. Können. Genau so. Dann haben wir noch die Buchstaben S und T bei Invest. Die letzten meinen S steht für Small, das ist denke ich auch hin hinblicklich unserer goldenen Regel. Ich find goldene Regel super klasse, dass du es so genannt
hast. Dass man halt sagt, OK, es muss halt auch umsetzbar sein, beispielsweise innerhalb eines Sprints. Also es darf jetzt nicht so ne Never ending Story werden, kleiner Anzug, kleiner Anzug, kleiner Anzug, wenn n Sprint 4 Wochen dauert, dann ist es nicht gut irgend ne user Story zu haben, die auch wirklich 4 Wochen dauert. Also ich sag mal so, ich persönlich bin bisher mal gut gefahren, wenn man es wirklich hinkriegt zu sagen ein bis 3 Tage.
Wenn das so umfasst, wenn das das umfasst, eine Story, dann ist es eine gute Story. Ja, da kommen wir in ganz andere Bereiche jetzt, weil ein Sprint sollte in meinen Augen keine 4 Wochen dauern, aber da gibt es auch Leute, die haben andere Meinungen, sehe ich ja, es ist halt immer, es ist halt immer eine Frage wie lange ist dieser Sprint, es sollte sagen wir mal so, es sollte definitiv nicht. Über ne Sprintlänge gehen die
wir für gut finden. Ein bis 2 Wochen sagen wir mal 2 Wochen, jetzt dann auf keinen Fall, dass es über 2 Wochen geht, das 1 bis 3 Tage was du meinst gehe ich mit weil es den anderen Punkten wieder in die Karten spielt, zum Beispiel schätzbarkeit du kannst Sachen aus meiner Sicht nicht schätzen, wenn du schon bei 23 Wochen Aufwand bist, dann kann dann wird es halt viel zu ungenau. Das Ding ist außerdem bist du da wieder bei Zeit am Ende? Egal. Das hatten wir alles schon mal besprochen.
Liebe Zuhörer, liebe Zuhörer, was ich eigentlich nur meine ist, es kommt ja gerne mal zu dem Punkt, dass man sich dann also vielleicht denkt sich jetzt irgendjemand was ein Tag, ne Story niemals gar auf gar keinen Fall, das kann nicht funktionieren, so okay lass mal sacken, probier doch einfach mal zu sagen, was müsste man tun damit es geht und nicht zu sagen. Nö, geht nicht.
Das ist das ist Bullshit, das ist Blasphemie, also also sozusagen einfach mal kurz zu den die Perspektive zu wechseln, auch wenn man vielleicht dann am Ende dazu kommt, so, es wird wirklich schwierig, OK, aber man hat zumindest mal seinen seine Gedanken, seinen Gedanken in Anstoß gegeben, in die vielleicht in die richtige Richtung.
Ja. Und ja, dann der letzte Buchstabe noch zum Abschluss testable ja, die klaren Akzeptanzkriterien helfen natürlich, um beispielsweise das Ticket abzunehmen oder zu reviewen, dass man sagt, OK, ich probier jetzt dieses Szenario durch die funktionieren. OK, es ist für mich getestet. Ich hab dieses Feature ausprobiert, es funktioniert und damit ist die User Story dann
auch abgeschlossen. Testable ist übrigens n richtig guter Punkt, weil du kannst wenn du sagst ey ich hab hier zum Beispiel n Akzeptanzkriterium mit diesem Given ran zen. Kannst du rein theoretisch ein Akzeptanz Kriterium in einen Test in deiner Software in einen automatisierten Test gießen um zu sagen ich nehme jetzt das, packe das in einen Test und dann
hast du 2 Sachen abgedeckt? Erstens hast du ein Test dafür für dein Akzeptanzkriterium automatisiert in der Pipeline laufen irgendwann hoffentlich Punkt 1.2 was auch super geil ist. Ist, dass du am Ende auch wirklich eigentlich in deinen Tests lesen kannst. Was soll denn die Anwendung können? Weil du ja eigentlich jedes Akzeptanzkriterium irgendwo abgebildet hast in deinen Tests Code Dokumentation für Entwicklerebene. Ja, absolut.
Also das hilft dir natürlich auch überhaupt, deine Tests dementsprechend gut zu gestalten. Ja. Ja, da würde ich sagen, das war so das Invest Modell was noch mal kurz und knapp zusammenfasst, was wir so hier ausführlich besprochen haben.
Zu den Best Practices würde ich auch noch mal ganz kurz zusammenfassen, was aus unserer Sicht jetzt so Do's and Don't sind, also Do's auf jeden Fall Personas nutzen um die Sicht des Endbenutzers zu verstehen wie du anfangs meintest ich als Nutzer der Seite, ich als Admin. Und so weiter.
Es muss immer gemessen werden. Was ist der Erfolg dieser Story, also was ist der Mehrwert und was muss erledigt werden, damit dieser Mehrwert eintritt, ist für mich so ein ganz wichtiger Punkt ist warum, warum mache ich das hier eigentlich und damit meine ich nicht, dass man morgens bei 09:00 Uhr beim Kaffee sitzen sich denkt, warum bin ich eigentlich hier, nein, sondern warum diese User? Story.
Dann hatten wir noch den Punkt, den wir aus eigener Erfahrung kennen, dass Refinance da einfach auch reinspielen und wichtig sind, regelmäßig zu refinen, weil Tickets leben, also Tickets, also user Stories, die Leben.
Sie können sich ändern, es kann in der Entwicklung können noch Sachen auffallen, dass zum Beispiel Akzeptanzkriterien nicht bedacht wurden, man kann nicht immer alle Fälle gerade so Edge Cases nicht im Kopf haben und deswegen so User Stories leben und können Refined werden Feedback auch ne ganz wichtige Sache. Das haben wir jetzt so indirekt besprochen, auch durch Refinement zum Beispiel, oder also angenommen, der PO schreibt dir jetzt dieses Ticket und er
macht es wirklich gut, dann erwartet er ja trotzdem auch so Feedback, beispielsweise vom vom Entwickler in die Richtung oder auch Richtung Stakeholder wieder hey hier die User Stories umgesetzt und so weiter da sind wir dann in der Feedbackkultur. Auch Edge würde ich noch Edge Cases. Zurückspiegeln ist auch gut, weil dann.
Bildet vielleicht auch sozusagen die Seite der Stakeholder auch n Verständnis dafür zu sagen oder NN Gespür dafür zu sagen, OK Moment, warte mal, wir hatten jetzt in der Vergangenheit immer mal so n paar Edgecases, das sollten wir in Zukunft auch gucken, dass wir vielleicht sowas auch mit ins ganz. Genau ziehen ne genau und das Zurückzuspiegeln hast du recht, ist ne ist halt genau diese Feedbackkultur die unfassbar wichtig ist. Ja, und ganz wichtig noch die
Abhängigkeit minimieren. Man kann sie nicht immer vollständig eliminieren, aber sie sollten sehr gering gehalten werden und es gibt Möglichkeiten trotzdem User Stories autark behandeln zu können, beispielsweise hey ja, ich kann mich nicht registrieren wie du meintest, ja, aber ich kann trotzdem das Login implementieren, indem ich einfach Dummy user hab die Regel als registriert gelten sozusagen und dann brauche ich nicht die Funktionalität mich registrieren
zu können. Ja, das sind so die Do's, würde ich sagen. Die Don't sind aber fast noch wichtiger und da ganz als allererstes, weil du es mehrfach genannt hast. Die Leuchtschrift, die Leuchtschrift, das größte Don't ist technische Details, wenn es eigentlich darum geht fachlich zu beschreiben, was die Story ist. Dahinter also nicht sagen, der User XY würde sich sehr gerne auf der Seite einloggen, aber mit dem Authentifizierungsverfahren.
Das macht halt keinen Sinn und das gehört da auch nicht rein. Das erschwert nur das Ticket abzuarbeiten ist überhaupt zu verstehen, es bläht so n Ticket extrem auf wie wir gesagt haben und das ist einfach keine gute Practice. Als nächstes könnt ich ja kurz weitermachen, dass man zum Beispiel Stories nicht zu groß macht. So also man spielt da quasi wieder mit rein, genau, also nicht zu viel reinballern und was auch wichtig ist, Stories sollten ne gewisse Struktur haben.
Weil es bringt nichts, wenn du sagst, ich Klatsch jetzt einmal, wie ich am Anfang meinte, einfach so ne Mail, irgendwie werf ich über n Zaun und dann so mach mal hier wird schon irgendwie hinhauen, das führt meistens eigentlich würde ich sagen zu 100 und ein Prozent immer dazu, dass es nicht gut funktioniert und das am Ende einfach viel zu viel Zeit ins Land fließt um diese Aufgabe im Endeffekt abzuschließen, ja. Genau dann wichtig ist auch, Stories ohne Nutzen zu
formulieren. An der Stelle muss man immer gucken, okay welchen Wert bietet diese Story, weil wenn du am Ende irgendwas schreibst, was wo man sich so denkt, so okay die Anwendung mit oder ohne ist eigentlich völlig Käse, was bringt mir das, bietet keinen Wert, bietet die Story keinen Wert, ist es kein user Story man kann differenzieren finde ich zwischen sogenannten Chaws wie ich das kenne das sind.
Auch Aufgaben, die kein User Value bringen, die aber technisch sozusagen die Anwendung verbessern. Also wenn du zum Beispiel eine gewisse Art von Refactoring hast oder deine Architektur so umstellst, dass du zum Beispiel schnellere Verarbeitungszeiten hast oder keine Ahnung, deine Architektur, die du verwendest, nur noch die Hälfte kostet oder was auch immer, solche Dinge die Anwendung macht genau das
gleiche wie vorher. Der User merkt davon aber nichts, aber es ist quasi technisch optimiert so. Aber das sind zum Beispiel auch Aufgaben, die definitiv natürlich vom Entwicklerteam geschrieben werden und ich kenne das in dem Sinne keine keine User Stories, so wie wir sie hier definieren, genau und ansonsten vielleicht noch der letzte Punkt, dass man eben nicht.
Sag ich jetzt mal akzeptanzkriterien so verwurstelt, dass man sie eigentlich gar nicht richtig reviewen kann, dass man irgendwie nicht in der Lage ist Herauszukristallisieren oder diese Testbarkeit zu haben um zu sagen, OK was also man sollte immer gucken, ne, wie kann man denn zum Beispiel auch aus nicht technischer Sicht ne Story abnehmen und wenn man das jetzt in Don't packt, muss man einfach die Akzeptanzkriterien sollte man nicht schwammig formulieren.
Ja oder gar keine haben ja. Wäre auch nicht so gut. Ja genau das sind so das noch mal knapp zusammengefasst, also schnell zusammengefasst. Der Inhalt der heutigen Folge der heutigen Folge meine Güte so, deswegen würde ich sagen, würde ich jetzt auch die Folge beenden.
Wir haben jetzt auch schon ne sehr fortgeschrittene Zeit, weil das Thema einfach so wichtig ist und so umfangreich, man könnte mehrere Folgen da drüber machen und ich hoffe, dass wir dem auch gerecht geworden sind, auch noch mal liebe Grüße an Veronika.
Und ja, es hat mir mega viel Spaß gemacht und vielen Dank für das für den Austausch. Ja dann würde ich sagen, bleibt mir nichts anderes über als die Folge zu beenden und deswegen, liebe Zuhörer, liebe Zuhörer, falls du Feedback hast, Fragen oder auch Anmerkungen zu der Folge, lass es uns gerne wissen, schreib uns ne Mail, meld dich auf den Social Media Kanälen. Wir freuen uns über jede Nachricht.
Schreib uns auch gerne von User Stories von Erfahrung, die du hattest, die so richtig absurd waren. Sowas finden wir auch immer super, da können wir auch eigene noch berichten, dann da können wir an n Austausch kommen wenn dir der Podcast gefällt, lass gerne ne Bewertung da empfehlen gerne weiter es hilft uns enorm uns hier noch zu verbessern und auch andere Leute daran teilhaben zu lassen.
Du findest in den Shownotes auch n kleinen Spendling falls du uns so unterstützen möchtest, dann vielen vielen Dank dafür. Und ja, ansonsten würde ich sagen, hören wir uns alle beim nächsten Mal wieder. Ich wünsche euch noch eine schöne Weihnachtszeit und bis dahin deine Coding Buddies. Gemeinsam besser.