User Stories schreiben, über den hohen Zaun zum Dev-Team werfen und 2 Wochen abwarten.
Das würde man mal wohl Water-Scrum-Fall nennen 🙂
Ich habe mich mit dem agilen Coach Andreas Becker getroffen, um zu diskutieren, wie man richtig gute User Stories schreibt.
Dabei die erste Erkenntnis:
Eine User Story ist kein Spezifikationsmittel, sondern ein Kommunikationsmittel
Es heißt zwar User Stories schreiben, es ist jedoch eher ein Gesprächsangebot für das Entwicklungsteam, um eine Diskussion zu unterstützen und damnit eben nicht in die Falle des Water-Scrum-Falls zu tappen.
Durchgesetzt hat sich dabei die Struktur “Ich als <Rolle> möchte <was machen>, um <Mehrwert> zu haben.
Mit dieser ersten Formulierung geht der Product Owner dann ins sogenannte Refinement, um mit dem Entwicklungsteam die unterschiedlichen Blickwinkel zu betrachten und die User Story weiter zu verfeinern.
Bevor das alles beginnt, muss das “große Ganze” jedoch erst eimal geschnitten werden.
Das bedeutet, dass das Projekt mit einer Methode wie z.B. User Story Mapping in Epics zerteilt wird und diese anschließend in User Story.
Welche weiteren Techniken es zum Schneiden gibt erfährst du in der Podcast-Folge.
Die Akzeptanzkriterien beim Schreiben von User Stories
Das Verwenden der u.g. Vorlage allein reicht allerdings noch nicht aus. Um später objektiv zu erkennen, wann die User Story fertig realisiert wurde, werden der User Story sogenannte Akzeptankriterien hinzugefügt. Dies kann mit Hilfe von Stichpunkten, Sätzen oder auch BPMN-Diagrammen passieren. Hierbei ist alles erlaubt, was die Umsetzung eindeutiger macht und für das Entwicklungsteam mehr Klarheit bringt.
Personas beim Erstellen von User Stories sind immens wichtig! Warum eigentlich?
Andreas hat ein tolles Beispiel in der Podcast-Folge, welches zeigt, wie wichtig es ist, dass alle verstehen, wer der spätere Anwender des Systems ist.
Bei einem Automobilhersteller gab es eine Anforderung, dass die Heckscheiben eine Rückwärtsfahren von 80km/h aushalten müssen.
Keiner konnte sich daran erinnern, warum das wichtig sein soll.
Wer fährt denn mit 80km/h rückwärts?
Die Gummies im Heckrahmen wurden durch billigere Gummies ersetzt.
Was dann passierte hörst Du dir am besten selbst an …
Danach weiß jeder, warum es wichtig ist, die Rolle beim User Stories schreiben, zu definieren.
#015
Und hier kommen die Details
Wie schreibt man eigentlich gute User Stories?
Also ich glaube User-Story, was das ist, das werden viele wissen. Gemäß der Vorlage als Rolle möchte ich das machen, um Mehrwert zu erreichen. Das ist noch relativ einfach, aber wenn man das Ganze mal vor sich hat und hat so ein großes Projekt und will das zerhacken und geht dann wirklich ran an den Schreibtisch, dann stellt man sich schon einige Fragen und überlegt: Wie komme ich dann überhaupt von dem großen Ganzen in diesen kleinen User-Stories? Und was mache ich denn zum Beispiel mit nicht funktionalen Anforderungen? Packe ich die auch in User-Stories oder ist das, wenn wir jetzt uns über Scrum unterhalten, wäre das ein Teil von der Definition of Done? Oder was passiert eigentlich mit juristischen Anforderungen? Na ja, es gibt auf jeden Fall eine ganze Menge Fragen. Und insofern freue ich mich total, Andreas, dass du da bist. Noch mal herzlich willkommen und ich würde sagen, starten wir direkt los, oder?
00:01:44
Ja, gerne.
00:01:45
Gut. Was ist dann überhaupt der Unterschied zwischen einer User-Story und zwischen einer Systemanforderung, so wie wir das vor zehn, fünfzehn Jahren gekannt haben?
00:01:57
Wir haben ja vor 15, 20 Jahren schon zusammengearbeitet. Stimmt und wir haben uns viel mit Systemanforderungen auseinandergesetzt. Der Hauptunterschied ist, das eine basiert auf reiner Dokumenten Arbeit. Die Systemanforderungen, die haben wir damals in Lastenhefte geschrieben und die User-Story, die ist genau das Gegenteil davon. Ich sage immer, eine User-Story ist kein Spezifikationsmittel, ist kein Spezifikationsersatz, so wie wir das früher gemacht haben, sondern das ist ein Kommunikationsmittel.
00:02:33
Das ist interessant. Das mit dem Kommunikationsmittel, das erklärst du gleich bestimmt auch noch. Da habe ich damals auch schon verstanden. Das ist im Prinzip ein Gesprächsangebot, aber dass das kein Spezifikationsmittel ist, da musst du noch mal mehr drüber erzählen.
Aufbau einer User Story
00:02:50
Also, dass da natürlich was aufgeschrieben werden kann. Ja, wenn es nötig ist, das fällt sozusagen hinten bei rum. Aber das Wichtige ist, dass man über das, was man gerne hätte, für wen es ist und vor allem, wozu es ist, in der Runde derer, die das umsetzen sollen, spricht, damit jeder verstanden hat, um was es geht. Und dann können wir auch gerne die Details aufschreiben, zum Beispiel in Form von Akzeptanzkriterien. Dann ist das eher so ein Protokoll. Wir haben diesen Satz, den du gerade vorgestellt hast oder dieses Template. Als Rolle möchte ich die Funktionalität und um was zu erreichen. Das ist sozusagen der Auftakt, aber das kann ja nicht alles sein, da muss ja noch was, da müssen ja noch Details folgen. Und das muss man in Formen dieser Akzeptanzkriterien, die wir natürlich auch aufschreiben können. Aber viel, viel wichtiger ist, dass die, die das machen müssen, verstanden haben, um was es geht. Und wenn sie es verstanden haben, dann reichen Stichpunkte bei den Akzeptanzkriterien, die unten drunter stehen. Wenn man ein wenig mehr schreiben will, kann man auch durchaus Sätze schreiben, aber die Kommunikation, die steht hier im Vordergrund und nicht die Spezifikation.
00:04:06
Okay, das heißt, es ist nicht gottgegeben diese Struktur zu nutzen. Kannst du das schon mal bestätigen?
00:04:12
Na ja, man ist frei natürlich, was man da nutzt. Ich finde dieses Template deswegen super, weil es schon mal drei wichtige Fragen beantwortet, nämlich:
Für wen mache ich das denn eigentlich?
In unseren alten Anforderungen stand das nie drin, für wen das eigentlich sein soll. Da stand nur drin, was wir haben wollen. Das steckt da auch in diesem Template drin. Und was ich ganz wichtig finde. Das auch noch das Wozu drinsteckt.
Wozu benötigen wir denn das?
Das hilft zum Beispiel bei der Priorisierung. Wenn ich nicht weiß, wozu ich etwas benötige, kann es durchaus sein, dass ich es wegpriorisiere. Und ich hätte das ein oder andere Beispiel für dieses Wozu? Da wird es noch mal klarer, warum das ein doch so wichtiger, vielleicht der wichtigste Bestandteil ist.
Ich war mal in einem Projekt. Ja, Automobilindustrie und da gab es eine Systemanforderung und die hieß so sinngemäß: Die Heckscheibe, also das sind die Scheiben, die hinten sind, müssen eine Geschwindigkeit von 80 km/h aushalten. Und es war Gott sei Dank nicht in meinem Projekt, sondern im Nachbarprojekt. Und die Folge war, dass man sich irgendwann mal über diese Anforderung gebeugt hat und hat gesagt: Was ein Unsinn, Heckscheibe, das ist doch hinten. Also wenn wir rückwärtsfahren würden, dann muss das 80 km/h aushalten. Das braucht man nicht, das kann viel geringer sein. Wir ändern die Einfassung, die Gummis, das geht günstiger, das beschaffen wir für kleines Geld. Dann sind es halt nur 10 oder 20 km/h. Aber schneller kann man doch gar nicht rückwärtsfahren. Also gemacht, eingespart. Und das ging so lange gut, bis die Autos auf den Zug kamen, auf den Transporter und wurden von hinten drauf gefahren. Also die Heckscheibe waren vorne und es kam der Fahrtwind von vorne und dann sind die Scheiben rausgeflogen. Das fand ich ein super Beispiel. Es wusste nämlich keiner den Grund. Der Grund war nicht bekannt, warum das so wichtig ist, dass die 80 km/h aushalten müssen. Nicht weil man rückwärts fährt, sondern für den Transport musste das geeignet sein. Und das war für mich ein super Beispiel, dass der Grund für eine Anforderung einen echten Mehrwert liefert.
00:06:52
Tolles Beispiel. Ja, echt klasse.
00:06:54
Ich hätte noch ein anderes. Haben wir noch die Zeit?
00:06:58
Ich würde gerne eine Frage anschließen daran, die mir gerade eingefallen ist. Und zwar ich frage mich gerade, wie lang lebt denn so eine User-Story überhaupt? Weil wenn du sagst, es ist kein Spezifikationsmittel und ich überlege, ich habe vielleicht nichts anderes. Man kann die User-Story sicher ziehen, kann die umsetzen und schiebt sie dann normalerweise nach dann. Und dann ist sie ja weg vom Fenster. Das heißt diese klassische Requirements-Trace-Ability. Nach drei, vier Jahren passiert etwas und ich muss da noch mal feststellen können: Was haben wir denn damals überhaupt vereinbart? Was ist denn da passiert? Auf welcher Umgebung haben wir das getestet? Daher noch mal die Frage. Wie lange lebt so eine User-Story? Und kann man diese Requirements-Trace-Ability überhaupt noch abbilden?
00:07:45
Also wenn ich sie brauche, kann man die durchaus abbilden. Habe ich auch schon gemacht. Beispiel Medizinprodukt für den US-Markt um da eine Zulassung zu bekommen. Für ein Medizinprodukt muss diese Trace-Ability natürlich gegeben sein. Von wem kommt diese Anforderung? Wo ist die Anforderung beschrieben? Und das war dann in Form einer User-Story bis runter in den Code. Wie habt ihr das umgesetzt? Und wenn das notwendig ist, kann man das natürlich auch tun. In vielen Fällen ist es nicht notwendig, da lässt man es sein. Aber wenn das zur Zulassung führen muss, dann macht man das natürlich.
00:08:22
Das heißt, wenn ich jetzt zum Beispiel Jira benutze, Wie mache ich das praktisch?
00:08:28
Ich mache das mit der Definition of done. Das, was du gerade beschrieben hast, das ist die reine Umsetzung, aber es ist in vielen Organisationen notwendig, dass das erhalten bleibt. Das heißt, ich schiebe das ins Archiv, ich hebe das auf, das muss nicht in Form von: Ich habe alles auf Zettel geschrieben, auf Post-its und wenn ich es umgesetzt habe, wenn es of done ist, kommt es in einen Papierkorb. Ich kann das auch durchaus archivieren. Wenn ich das benötige, sollte ich es tun.
Das Runterbrechen des Produkts in User Stories
00:08:55
Okay, gehen wir noch mal einen Schritt zurück. Wenn ich als Projektleiter oder als Product Owner in der Produktentwicklung jetzt reinkomme und habe die Aufgabe, etwas Großes zu strukturieren, also mein Chef kommt zu mir und sagt: Pass mal auf, wir wollen folgendes neues, cooles Produkt bauen. Das sind die strategischen Ziele davon, das soll erreicht werden. Jetzt muss ich ja von dem großen Ganzen kommen und muss hinterher diese User-Stories haben. Wie gehe ich denn dabei am schlausten vor?
00:09:27
Also was du jetzt ja beschreibst, ist neu. Also grüne Wiese. Wir wollen was völlig Neues machen. Es passiert leider nicht so häufig, aber wenn es passiert, dann arbeite ich immer erst mal mit einem Big Picture und das wird visualisiert. Und das mache ich gerne mit der Methode Story-Mapping. Die ist dafür hervorragend geeignet. Was sind denn die Ziele, die wir damit erreichen wollen? Wer ist da involviert und was ist beispielsweise mein Prozess, der mich zu dem Ziel führt? Und was sind Funktionalitäten, die diese Prozessschritte unterstützen? Und diese Unterstützungsleistungen sind dann häufig User-Stories. Story-Mapping, also da könnten wir im Prinzip allein eine eigene Folge aufnehmen, wo wir das machen.
00:10:15
Das machen wir sehr gerne. Ja doch, hört sich gut an, wir müssen gucken, wie wir das audiotechnisch hinbekommen, weil das ja ziemlich visuell ist mit den einzelnen Kärtchen. Aber das kriegen wir schon rübergebracht. Das macht Sinn.
00:10:28
Okay, das glaube ich, würde jetzt den Rahmen sprengen, wenn wir sagen: User-Stories, da gibt es nämlich auch schon sehr, sehr viel zu sagen. Und Story-Mapping, wie gesagt, davon können wir eine eigene Folge aufnehmen.
00:10:41
Gerne. Okay, das wäre also die Methode. Das heißt, am Anfang steht wahrscheinlich auch die Produktvision wieder erst mal.
00:10:48
Genau um was geht es eigentlich, dann das Ganze mal zu visualisieren in Form von, kann man gerne Story-Mapping nehmen und das würden wir jetzt im Prinzip einmal auslassen und wir gehen direkt wieder zur User-Story?
00:11:02
Kommt das als Nächstes? Also fangen wir mal ganz vorne an. Wir haben ganz oben die fünf Ziele, sage ich mal. Oft ist es ja wirklich so, dass jemand kommt und sagt: Pass auf, ich möchte gerne folgende Sache umgesetzt haben und dann habe ich die Produktidee, sag ich mal einfach. Dann haben wir gesagt, wäre gut, die Produktvision zu bauen. Dann kann ich heruntergehen mit meiner Methode, wie zum Beispiel Story-Mapping und bekomme ich dann schon die User-Story raus oder gibt es noch etwas dazwischen?
Definition eines Epic und einer Abgrenzung zur User Story
00:11:30
Da gibt es was dazwischen wahrscheinlich. Warum ich wahrscheinlich sage, das möchte ich gleich erläutern, das ist das Epic. Also ich habe jetzt eine Funktionalität, ich habe irgendetwas Großes, einen großen Funktionalitätsblock, den ich und die meisten nutzen ja User-Story, um mit Scrum in Sprints vielleicht von zwei Wochen etwas umzusetzen. Und jetzt ist das aber zu groß, wesentlich zu groß. Und dann würden wir das Epic nennen. Und ein Epic ist nicht definiert, wie das auszusehen hat. Die User Story, die ist ja definiert. Als Rolle möchte ich Funktionalität damit, das hattest du zum Einstieg gesagt. Das Epic ist nicht definiert. Das ist etwas Großes, was noch nicht Sprint tauglich ist. Aber wie das aussieht, das ist nicht definiert. Aber meine Empfehlung ist: Schreibe doch mal das Epic genauso wie die User Rolle, macht da keinen Unterschied. Nimm dieses Template, beschreibe das mal und überlege dir mal Akzeptanzkriterien. Wann ist denn dieses Große fertig? Wann bist du denn zufrieden? Und du wirst in den meisten Fällen feststellen, es ist zu groß. Ich muss es herunterbrechen, ich muss es klein schneiden.
Übers Schneiden können wir vielleicht nachher auch noch reden, dann muss ich das tun. Es gibt aber keine Musterlösung. Wann ist etwas ein Epic und wann ist es schon eine User-Story? Und das hängt am Kontext. Ich nenne dir da ein Beispiel für. Angenommen du hast ein Entwicklungsteam mit acht Entwicklern und die sind im vier Wochen Sprint. Die nehmen dir ein Epic. Also was groß ist und sagen: Ja, klar bekommen wir das unter. Wir haben ja vier Wochen Sprint, wir sind acht Leute. Dann gehst du mit demselben Epic zum Nachbar-Entwicklungsteam. Da sitzen nur drei Entwickler und die arbeiten im zwei Wochen Sprint. Und die sagen dir: Was, das riesen Epic? Das bekommen wir nie unter in unseren zwei Wochen. Wir sind ja auch nur zu dritt. Das heißt, es ist immer kontextabhängig. Und das schließt sich jetzt auch wieder der Kreis.
Eine User Story is kein Spezifikationsmittel!
Am Anfang hatte ich ja gesagt, das ist kein Spezifikationsmittel, sondern das ist ein Kommunikationsmittel. Du musst die Leute einbinden, du stellst denen was vor und die schätzen das ab und dann wird sehr schnell herauskommen, bekommen wir unter oder bekommen wir nicht unter. Und du kannst nicht im stillen Kämmerlein sitzen und sagen: Haha, das ist eine User-Story und das ist ein Epic und ich definiere das mal, du musst die Leute mit ins Boot nehmen.
00:14:03
Gut, ich glaube, den ersten Aufschlag muss ich als Product Owner ja schon selbst machen? Dass ich sage, ich schreib mal erst mal etwas wie eine Story. Und dann gibt es das Refinement, wo ich mit den Entwicklern zusammensitze. Und da unterhalten wir uns und sagen: Ja, wir schätzen und gucken.
00:14:19
So und das Ergebnis, ob etwas zu groß ist oder zu klein, das ist immer abhängig. Und deswegen gibt es auch keine Musterlösung. Ich kann nicht sagen, wenn wir jetzt etwas definieren würden, das ist schon eine User-Story und das ist ein Epic, sondern du musst die Leute mit einbeziehen. Und genau deswegen ist es ein Kommunikationsmittel. Es ist ein super Aufschlag, genauso wie du es gerade gesagt hast. Du kommst als Product Owner zum Team und hast da schon mal was vorbereitet. Ob das denn jetzt passend ist, ob da noch was fehlt, ob da was rausmuss und ob es überhaupt in den Sprint reinpasst. Das musst du mit den Leuten ausmachen.
00:14:51
Also im Prinzip eine Art Containerformat. Einen Container kann ich füllen, aber der Container selbst hat wenig Wert.
00:14:59
Genau. Wenn wir vom Schneiden von User-Stories sprechen, es gibt da ja so ein paar Techniken, können wir vielleicht nachher anreißen, dann ist es gut, wenn diese Technik auch im Team bekannt sind. Dann könnt ihr das nämlich zusammen im Refinement mitmachen. Wenn nicht nur der Product Owner über diese Techniken verfügt, sondern auch die Teammitglieder, dann kann man sich gemeinsam hinsetzen und überlegen: Was macht denn jetzt Sinn? Am Ende muss da ja noch ein Mehrwert entstehen von so einer User-Story. Und wenn wir das gemeinsam machen, dann können wir überlegen, welche Schneidetechnik passt, was passt in unseren Sprint hinein? Und so kann man individuell von Team zu Team die Epic zu User-Stories machen.
User Stories Beispiel
00:15:44
Ja, mach mal gerne ein Beispiel mit Schneidetechnik.
00:15:48
Also, was ich gerne mache, ist eine Beispielstory nehmen. Die habe ich vor vielen Jahren genommen, weil ich zu Hause saß und dachte, ich habe jetzt hier so ein tolles Tablet. Aber egal wer es benutzt, es ist immer die gleiche Oberfläche, die gleichen Einstellungen. Es gibt keine Benutzerverwaltung. Ich dachte: Ach, eigentlich wäre es doch schön, ein Tablet hätte auch so eine Benutzerverwaltung. Und dann habe ich mal formuliert, als Tablet Nutzer möchte ich eine Benutzerverwaltung, damit individuelle Einstellungen pro Benutzer möglich sind. Das wäre jetzt erst mal ein Auftakt. Nennen wir es mal Story, weil das ja diesem Format folgt. Jetzt ist ein Tablet Nutzer noch sehr grob. Und jetzt geht es nämlich schon los. Angenommen, wir würden das nehmen. Ich gehe mit dieser Story zum Entwicklungsteam, dann kommen genau solche Fragen. Und dann geht es nämlich auch weiter. Ja, was heißt denn das jetzt? Jetzt sind wir nämlich sehr schnell bei den Akzeptanzkriterien. Du willst Benutzerverwaltung. Ja, was sollen wir denn da alles verwalten? Mehrere Leute? Okay. Ja, wie viel denn? 2, 3, 5, unendlich? Wenn wir es nicht definieren, dann kommt was auch immer raus. Haben die unterschiedliche Rechte? Haben wir so was wie: Wenn das im familiären Umfeld jetzt genutzt werden soll, haben wir dann so was wie ein Familienadministrator? Aber Standardnutzer haben vielleicht Kinder, die eingeschränkte Nutzer haben. Es kommen viele Fragen hoch in diesem Zusammenhang. Was soll denn überhaupt individualisiert werden, wenn ich davon sprach, ich möchte individuelle Einstellung haben? Ja, was sollen das für Einstellungen sein? All diese Detailfragen, die müssen geklärt werden und das sind die Akzeptanzkriterien.
Wie schreibt man Akzeptanzkriterien?
Ich hatte ja eben das Beispiel gemacht, ich gehe in das eine Team und dann laufe ich rüber in das andere Zimmer und laufe zum anderen Team. Wenn ich nur mit diesem einen Satz arbeiten würde und würde diesen Satz: Als Tabletnutzer möchte ich eine Benutzerverwaltung, damit individuelle Einstellungen möglich sind. Wenn ich diesen Satz einfach so da stehen lassen und sage: Hier macht mir das und gehe zu dem einen Team und gehe mit demselben Satz zu dem anderen Team, dann bekomme ich völlig unterschiedliche Lösungen. Und genau das soll nicht passieren. Und genau deswegen benötigen wir die Akzeptanzkriterien. Was heißt das konkret? Und wenn die das aber verstanden haben, was das konkret heißt, dann ist die Ausformulierung fast schon zweitrangig. Dann kann sein, dass das Stichpunkte sind. Dann kann es sein, dass das Sätze sind. Dann könnte es sein, dass es Beispiele sind, Beispieldaten,Entscheidungs-Tabellen. Wenn das viele Verschachtelungsansätze beinhalten würde, wenn dann, wenn dann, wenn dann. Ja, dann mach ich so eine Entscheidungstabelle. Also es ist alles erlaubt, wenn es dazu dient, ein gemeinsames Verständnis über diesen Satz zu erzielen.
00:18:49
Okay, das heißt, ich kann die User-Story erweitern um die Dokumente, dass es eindeutig wird. Ich könnte zum Beispiel auch ein UML Schema dahinter packen, XML Tabellen, egal, was ein User-Workflow?
00:19:04
Wenn es zum Verständnis dient, meistens sind es nicht gleich ganze Dokumente, weil so eine Story ist ja vom Funktionsumfang eher kleiner. Das muss ja in den Sprint passen. Aber vom Prinzip hast du recht. Das, was ich benötige und das, was nötig ist, um ein gemeinsames Verständnis zu erzielen, was da hinten bei rumkommen soll, das nehme ich.
00:19:26
Ja, ich habe es wirklich mal gemacht. Ich habe ein BPMN, einen Workflow abgebildet und habe daraus ein Bild gemacht und das wiederum dann an der User-Story attached sozusagen. Und das hat den Entwicklern geholfen, dann den Prozess zu verstehen. Ja, okay, jetzt mal eine interessante Frage. Jetzt haben wir den Weg genommen, von generisch nach konkret. Das heißt, ich habe generisch etwas geschrieben und die Entwickler können nachdenken. Wie machen wir das denn? Manchmal ist es ja so, dass der Product Owner schon fünf Stufen weitergedacht hat und denkt sich: Ja, machen wir mal als Beispiel, wir wollen eine Videoplattform machen. Und das ist schon völlig klar aus bestimmten Gründen, welcher Video-Codec benutzt werden soll und welcher Audio-Codec. Also beispielsweise es soll h.264 benutzt werden für Video, MP3 für Audio. Frage: Macht es jetzt noch Sinn, dass ich sage, ich möchte gerne einen Videostream haben oder soll ich nicht, wenn ich schon genau weiß, wie das auszusehen hat, da reinschreiben als Akzeptanzkriterium oder in die Story, bin gespannt auf deine Antwort, bitte h.264 verwenden als Video-Codec und MP3 als Audio-Codec. Wie geht man damit um?
00:20:38
Also, ich würde das einmal hinterfragen. Es kommt in die Akzeptanzkriterien, dass ich genau das gerne hätte, aber ich würde tatsächlich erst einmal hinterfragen, warum das gesetzt wurde?
00:20:50
Wenn du Entwickler wärst.
00:20:51
Oder in meinem Fall ich laufe da ja mit in solchen Teams als Coach und dann stelle ich halt als Coach die Fragen: Warum hast du das jetzt vorgegeben? Und dann bin ich auf die Antwort gespannt. Es kommen nämlich mitunter solche Antworten wie: Ja, gibt es noch Alternativen? Also es passiert wirklich, dass jemand einfach etwas übernimmt, weil er nichts anderes kennt. Und mitunter wird schon die technische Lösung vorgegeben, weil man einfach nichts anderes kennt. Und manchmal ist es sinnvoll, wenn man das noch mal hinterfragt, muss man noch mal einen Schritt zurückgehen. Was willst du eigentlich damit erreichen? Was ist deine fachliche Anforderung? Und vielleicht gibt es mehrere Alternativen und das klärt sich in einem Refinement, wenn man diese Fragen stellt. Und dann passiert auch wieder das, was ich am Anfang sagte: Das ist ein Kommunikationsmittel. Da kommt einer mit einem Erstvorschlag und es kann sein, dass wir diesen Erstvorschlag zerlegen, weil wir eine bessere Möglichkeit sehen und dann können wir das anpassen.
An dieser Stelle habe ich jetzt einen Cut gemacht, damit die Folge einfach nicht zu lang wird. Was dich in der nächsten Woche erwartet bei der nächsten Folge, ist, dass wir die Fragen klären: Wie geht man mit den Tasks in Gira um? Wie schreibt man richtig gute Akzeptanzkriterien? Und wie grenzt man das ab zur Definition of Done? Und wie kann man User-Stories richtig gut schneiden? Also freue dich auf die nächste Woche. Montag kommt die nächste Folge raus. Bis dann. Mach’s gut.
-> Hier geht’s zum zweiten Teil:
https://leobalo.de/podcast/user-stores-schreiben-teil-2/
