Wie schlimm sind große Stories?

TL;DR - geht so...

Was ist eine Story?

Lasst uns mal damit anfangen, zu überlegen, was eine Story eigentlich ist. In meinen Augen beschreibt eine Story das, was ein User des Systems benötigt. Nicht mehr und nicht weniger. Wir können hier noch keine Größe ableiten, aber wir haben schon eine erste Erkenntnis:

Es geht vor allem darum, dem User etwas sinnvolles zu liefern. Das ist doch schonmal ein guter Ansatz!

Was ist klein und was ist groß?

Tja, das ist auch nicht leicht zu beantworten. Wir sollten daher mal an die Grenzen schauen, die ihr bei euch habt. Eine Story soll, wie oben geschrieben, einen Nutzen für den User des Systems haben. Daraus können wir schon einmal ableiten, dass wir sicherlich eine gewisse Mindestgröße haben werden. In den meisten Fällen dürfte das um ca. vier Stunden "Arbeit" liegen. 

Doch was ist mit der oberen Grenze? Ich weiß, dass es bei euch (und auch bei uns) Stories gibt, die ohne Probleme auch mehr als eine Woche "Arbeit" beinhaltet. Das bezeichne ich dann definitiv als groß. Ich habe auch schon Stories gesehen, an denen vier Wochen gearbeitet wurde...

Was sind deine Grenzen? Schreib mir doch gerne per Mail oder gleich direkt auf Mastodon!

Warum sind große Stories nicht gut?

Schauen wir nochmal auf die erste Erkenntnis aus diesem Artikel:

Es geht vor allem darum, dem User etwas zu liefern

Aha! Da ist unsere Antwort. Wenn es lange dauert, bis wir dem User etwas liefern können, dann vermisst unser User etwas. Und: Andere könnten schneller sein und dem User dieses "etwas" liefern. Das schwächt unsere Marktposition.

Und das ist der Grund, warum ich oben auf die Frage "Wie schlimm sind große Stories" mit "geht so..." geantwortet habe. Wenn ihr zu lange braucht, um dem User etwas zu liefern, dann ist das nicht gut. 

Wie bekomme ich Stories kleiner?

Okay, jetzt, wo wir das wissen, was tun wir? Eigentlich ist es gar nicht so schwer. Wir müssen uns die Story ansehen und überlegen, was das Minimum ist, dass dem User einen Wert liefert. 

Hier gibt es verschiedene Methoden. Ich persönlich mag Dimensional Planning sehr. Die Idee zu schauen, ob wir einen Feldweg oder eine Autobahn brauchen, ist ein einfaches Bild und sehr hilfreich. Schau dir gerne den verlinkten Artikel an. Hier erkläre ich, wie die Methode funktioniert.

Ich hör euch schon sagen: "Aber wir brauchen ALLE Funktionen für den User". Wirklich? Und was heißt denn "alle Funktionen"? Denk mal darüber nach: Kannst du wirklich voraussagen, was der User braucht? Ganz sicher?

• Falls ja: Glückwunsch! Und überleg mal, ob du den Overhead von agilem Arbeiten wirklich brauchst.
• Falls nein: Glückwunsch! Das geht uns allen so. Und deswegen bist du ja auch hier bei dem Artikel gelandet.

Viele machen beim Planen von Stories bzw. dem Planen der minimalen Features von Stories den Fehler zu vergessen, dass in weiteren Stories ein Feature ausgebaut werden kann. Im besten Fall sogar aufgrund des Feedbacks der User aus der minimalen Version, die ihr ja schnell liefern konnten, weil eure Story klein war.

Damit schließt sich dann auch schon der Kreis. Wie immer im agilen Arbeiten wollen wir an so vielen Stellen und so oft wie möglich Feedback. Einer der Hauptgründe ist genau das Thema, das wir in diesem Artikel herausgearbeitet haben: Welche Features möchte der User des Systems wirklich? Und das bekommen wir nur heraus, wenn wir etwas möglichst sinnvolles möglichst schnell liefern. Und daher sind große Stories eher schlimm.

Hinweis

Ich hoffe, du hast gemerkt, dass ich weder von Velocity noch von Cycle Time gesprochen habe. Dies sind nur Zahlen und jede Zahl kann man manipulieren. Wir haben diese Zahlen auch nicht, um schneller zu werden, sondern nur um zu schauen OB wir schneller geworden sind. Die Kausalität ist hier sehr wichtig - denk da gerne einmal drüber nach, wenn du dein Team und dein Umfeld anschaust.

Wie oben schon geschrieben, freue ich mich immer auf dein Feedback!