In Folge 16 von No Bullshit Agile erklärt Thomas, warum es sinnvoll ist, Stories klein zu halten. Kleine Stories bieten viele Vorteile, darunter einfacheres Handling, besseren Fokus, höhere Transparenz, Flexibilität, erhöhten Durchsatz und effektiveres Risikomanagement.

Thomas widerlegt die Argumente für große Stories, wie einfachere Handhabung oder Erhalt des Kontexts, und betont, dass der eigentliche Wert in der schnellen Lieferung und dem regelmäßigen Feedback liegt. Kleine Stories ermöglichen es Teams, schneller Wert zu schaffen und Anpassungen vorzunehmen. Er empfiehlt, Stories so klein wie möglich zu halten, um die Agilität zu maximieren und den gesamten Prozess zu optimieren.

Transkript

Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt dabei auf der Praxis, daher auch der Name No Bullshit Agile.

In der letzten Folge habe ich darüber gesprochen, dass Agilität vor allem ein Mindset ist und wie wichtig es ist, dies zu verstehen und zu verinnerlichen. Dies ist die Folge 16 und heute geht es darum, warum kleine Stories sinnvoll sind.

Bevor wir mit dem Thema anfangen, wie immer ein bisschen Housekeeping: Ich hatte zur letzten Folge, der Folge 15, auf Mastodon eine Umfrage gestartet. Die Frage lautete: „Wie zufrieden seid ihr mit der Agilität bei euch im Unternehmen?“ Und dabei ist folgendes herausgekommen:

Es gab drei Antwortmöglichkeiten:

„Ich bin total zufrieden“ – 8% haben das angeklickt.
„Da ist noch Luft nach oben“ – 50% haben das angeklickt.
„Obwohl wir es sagen, sind wir gar nicht agil“ – 42% haben das angeklickt.

24 Leute haben an der Umfrage teilgenommen. Vielen Dank auch an alle, die sie geteilt haben. Es gab auch einen ganz interessanten Austausch im Thread zur Umfrage. Da nochmal ganz direkt vielen Dank an Rosanna, Floatchain Senzai, Leonid, Bruno, Eva und Thorsten. Vielen Dank! Solche Interaktionen machen mir total Spaß und zeigen mir, dass der Podcast wirklich gehört wird und dass es Leute gibt, die sich gerne beteiligen. Das freut mich total und ist der Hauptgrund, warum ich diesen Podcast mache: um eure Meinung zu den Themen zu hören, die ich hier einmal die Woche bespreche.

Die Ergebnisse finde ich spannend. Es entspricht ein bisschen meinem Bauchgefühl und meiner Erfahrung, dass die meisten tatsächlich nicht vollkommen zufrieden sind mit der Agilität ihres Unternehmens. Ich vermute mal, dass es jetzt natürlich Interpretationen gibt: Agilität an sich ist schon eine coole Sache, aber die Umsetzung ist eben tatsächlich nicht trivial. Wenn ihr Lust habt, verlinke ich die Umfrage und damit auch den Thread in den Shownotes. Schaut gerne mal rein, was die Leute so zu dem Thema geschrieben haben. Wie gesagt, ich finde es super spannend und danke nochmal an alle für den Austausch.

Dann steigen wir mal in das Thema ein. Die Überschrift lautet: „Kleine Stories machen Sinn.“ Ich habe immer wieder Diskussionen erlebt, und erlebe sie zum Teil auch noch, bei denen Leute sagen, große Stories seien besser. Die Argumente sind oft: „Große Stories sind einfacher zu handhaben“, „Sie machen das Backlog nicht so voll“, „Der Kontext bleibt erhalten“, oder „Die Zerteilung kann man auch in Subtasks machen.“ Es gibt wirklich viele Argumente pro große Stories. Dies ist keine vollständige Aufzählung, aber ihr seht schon, worauf diese Argumente hinzielen.

Was ich auch schon gesehen habe, ist, dass ganze Projekte wirklich 20 Tage oder noch mehr in einer Story stecken. Ehrlich gesagt, habe ich dafür überhaupt kein Verständnis. Das ist wirklich nicht das, was eine Story sein sollte. Die Idee einer Story geht in einem solchen Fall völlig verloren. Deswegen vielleicht ein bisschen der Blickwinkel darauf: Was ist eine Story eigentlich?

Ganz grundsätzlich geht es darum, dass wir in einer Story eine Geschichte erzählen wollen. Wir wollen beschreiben, was der Benutzer des Systems mit dem System macht oder vielleicht sogar da erlebt. Eine Story soll einen Wert schaffen. Es ist immer wieder dieses Thema: Was tun wir, und wie schaffen wir letztendlich einen Wert? Ob für uns selbst, wenn wir für uns selbst entwickeln, oder für einen Kunden. Eine Story hat nichts mit der Verwaltung eines Projekts oder mit Projektmanagement zu tun.

Dann sind wir wieder genau an der Stelle, an der wir bei den Pro-Argumenten für große Stories waren. Wenn es heißt, „kleine Stories machen das Backlog schwieriger im Handling“ oder „wenn ich eine große Story habe, bleibt der Kontext erhalten“, dann ist das immer der Blick aus dem Projektmanagement. Methodiken wie Scrum oder Kanban sind aber nicht Projektmanagement-Methodiken. Sie sollen die Agilität unterstützen. Ich bin, wie ihr wahrscheinlich aus anderen Folgen kennt, nicht so sehr auf der Seite, wie Scrum oder Kanban funktioniert, sondern eher am Fundament der Agilität, am praxisnahen Aspekt. Deshalb orientiere ich mich am Agile Manifest und den 12 Prinzipien.

Eine Story soll so klein wie möglich und in sich geschlossen sein. Das ist die erste Aussage zu klein und groß und in sich geschlossen. Und ich weiß, dass es keine absoluten Größen für Stories gibt und ich würde das auch nie einführen. Ich würde nie sagen, das hier ist die maximale Größe einer Story, weil das sehr stark davon abhängt, was ihr tut und in welchem Umfeld ihr arbeitet. Aber die relative Aussage „so klein wie möglich“ kann man treffen. Das gehört zur Diskussion und zur Beobachtung einfach permanent dazu.

Diese Story, die wir hier haben, ist die wirklich so klein wie möglich oder gibt es organisatorische oder technische Gründe, warum wir sagen, die muss so groß sein? Dann kann man schauen, was man technisch tun kann, um den technischen Grund für große Stories Schritt für Schritt zu beseitigen oder auch den organisatorischen Grund für große Stories. Schlussendlich möchte ich in der agilen Welt, dass Stories so schnell wie möglich released werden können, um ihren Wert zu schaffen. Wert schaffen kann nur geschehen, wenn es am Markt ist. Dann kann es echte Euros einspielen, oder ich kann meinen Feedback-Zyklus starten und das Feedback zur Story bekommen, um zu sehen, ob sie am Markt funktioniert. Natürlich geht es auch darum, was der Kunde bezahlt hat; das soll natürlich Geld zurückbringen.

Die kleinen Stories werden uns auch bei der Vertragsgestaltung mit dem Kunden helfen. Ich werde eine Folge machen über „Agilen Festpreis“, „No Estimates“, und wie man agile Vertragsgestaltung mit Kunden macht. Da werden kleine Stories eine große Rolle spielen. Ha ha, kleine Stories große Rolle.

Zum Punkt „Was ist klein?“: Meine Erfahrung nach, wenn es irgendwie zwei Wochen bis zu einem Release dieser Story dauert, dann ist die Story zu groß. Der Abstand der Feedback-Zyklen ist einfach zu groß. Alles, was über zwei Wochen hinausgeht, ist, na ja, untragbar. Ich würde wirklich hart überlegen, was ihr euch mit solchen Zyklen wegnehmt. Viele von euch machen Scrum und haben Sprints. Höchstwahrscheinlich liefert ihr das Inkrement am Ende des Sprints. Zwei Wochen Sprint ist eine relativ typische Sprintgröße. Manche Leute gehen auf eine Woche, was ich deutlich besser finde. Es gibt natürlich auch Sprints, die mehr als zwei Wochen dauern. Das ist für mich ein Punkt, an dem ich denke, dass es in bestimmten Situationen und Umfelden gar nicht anders geht. Aber vielleicht könnt ihr darüber nachdenken, ob ihr innerhalb eines Sprints schon etwas liefert, um diesen Feedback-Zyklus zu bekommen und echten Wert zu schaffen.

Es gibt richtig gute und praxisrelevante Methoden, um Stories zu beobachten und sie kleiner zu machen. Ich habe einen Artikel in den Shownotes verlinkt. Es gibt viele Methoden, zum Beispiel die INVEST-Methode, die sehr praxisnah helfen, zu prüfen, wie man die Story noch kleiner bekommen kann.

Ich möchte gerne noch einige Argumente für kleine Stories bringen:

Einfacheres Handling: Kleine Stories sind leichter zu planen und zu sortieren. Sie erleichtern agiles Planen. Dazu gibt es auch eine Folge 13 zur agilen Projektplanung, die ich in den Shownotes verlinke.
Fokus schaffen: Es ist einfacher, den Fokus zu halten und Kontextwechsel zu vermeiden, wenn man mit kleinen Stories arbeitet, weil der Umfang überschaubarer ist.
Transparenz: Kleine Stories bieten bessere Transparenz über den Fortschritt. Dies hilft beim Daily, um zu erkennen, ob es Blocker gibt oder ob etwas nicht vorangeht.
Flexibilität: Ihr könnt die Reihenfolge der Stories besser steuern und an das Umfeld anpassen.
Erhöhter Durchsatz: Kleine Stories werden schneller fertiggestellt und der gesamte Prozess kann beschleunigt werden.
Risikomanagement: Kleine Stories bergen weniger Risiko und ermöglichen schnellere Reaktionen nach einem Release. Sie sind unabdingbar, wenn man in Richtung Continuous Delivery streben möchte.

Mein Tipp wäre, probiert es mal aus, wenn ihr das Gefühl habt, dass eure Stories zu groß sind. Beobachtet, wie lange es dauert, bis eine Story fertig ist, bis ihr Geld verdient oder Wert schafft, bis der Feedback-Zyklus startet. Versucht, Stories so klein wie möglich zu halten und berücksichtigt das bei neuen Stories. Lasst euch nicht von Tools wie Jira daran hindern, kleine Stories zu machen. Findet einfache Lösungen und lasst euch nicht von Tools leiten.

Was mich wirklich interessieren würde, ist, was für euch eine kleine oder große Story ist und wie lange ihr für eine Story braucht, bis sie fertig ist. Ich starte parallel zu dieser Folge eine Umfrage auf Mastodon und würde mich freuen, wenn ihr mitmacht, sie teilt und mit mir sowie anderen auf Mastodon diskutiert.

Das soll es für heute gewesen sein. Wie immer freue ich mich auf euer Feedback, auch auf kritische Meinungen. Das Ganze ist für mich ein Diskussionsstarter. Wenn euch etwas nicht gefällt, schreibt mir das gerne. Wenn ihr Feedback jeglicher Art habt, gebt mir die Möglichkeit, euch zu erreichen. Ihr könnt mich per Mail unter nobsagile@gmail.com erreichen oder auf Mastodon finden. Es gibt auch ein Forum, wo wir uns austauschen können. Ich freue mich auf euer Feedback.

Dann wünsche ich euch noch eine ganz tolle Woche und wir hören uns beim nächsten Mal. Ciao, ciao.

NBA16: Kleine Stories machen Sinn

Shownotes

Zusammenfassung

Transkript

Featured

Subscribe

Tags