Die User Story perfektionieren – so geht’s!

Die User Story ist eine gängige agile Praktik, die es dir erlaubt Anforderungen aus Sicht der Benutzer und Anwender festzuhalten. Die User Story ist recht populär und wird in viele Scrum Teams angewendet. Ich zeige dir in diesem Artikel, wie du sie schreibst, auf was du achten musst und welche Feinheiten es gibt, damit du diese perfektionieren kannst!

Historie

Die Historie der User Story geht weit zurück. User Stories kommen aus dem Kontext des Extreme Programming um das Jahr 1998 rum.

Aufbau einer User Story

Die drei C's einer User Story

User Stories bestehen aus drei Komponenten, die zusammen das Artefakt der User Story ausmachen.

Card

Du kennst die Ausprägung "Card" bestimmt am ehesten, wenn du an eine User Story denkst. Denn das ist schließlich das Artefakt, mit dem du in Berührung kommst. Es geht um die geschriebene Karte bzw. die Abbildung in einem elektronischen Tool.

Conversation

Communication ist ein wichtiger Bestandteil, es geht dabei um das eingangs erwähnte Kommunikationsversprechen. Die User Story ist als verhandelbar und es darf und soll darüber gesprochen werden. Zudem soll die User Story auch den Austausch darüber fördern.

Confirmation

Natürlich müssen wir erkennen können, wann eine User Story abgeschlossen ist. Das ist oft nicht nur zwingend nötig, sondern setzt auch zu Beginn die richtige Erwartungshaltung an die Story selbst.

Lösung und Zielorientierung

Ein spannender Punkt, den du bei vielen Teams findet und auf den du unbedingt mal achten solltest: sind die User Stories und damit die Anforderungen zielorientiert oder lösungsorientiert?

Eine Entscheidung über die richtige oder falsche Verwendung einer der beiden Varianten kannst du nur für deinen Kontext fällen. Denn es hängt sehr von deiner Umgebung ab. Machen wir ein Beispiel:

Natürlich wirst du nun argumentieren, dass die Rollen unterschiedlich sind und es vielleicht ja auch in deinem Kontext total klar ist, dass der Autofahrer von A nach B mit dem Auto gelangen soll und nicht mit dem Dreirad. Absolut klar und logisch für mich - darum geht es mir hier an der ersten Stelle gar nicht. Ich möchte einfach nur Bewusstseins schaffen für:

Befolgen der INVEST Kriterien

Mit dem Akronym INVEST steht dir eine wertvolle Checkliste zur Verfügung. Damit kannst du deine Anforderungen und damit User Stories prüfen, ob diese eine gute Struktur enthalten.

Independent

Starten wir mit dem Buchstaben I. Independent bedeutet, dass die User Story unabhängig von anderen sein soll. Sie werden mit Sicherheit den Fall entdecken, dass Sie eine Story vor der anderen machen müssen. Vermeiden Sie aber User Stories zu schreiben, in denen Sie zum Beispiel 20 User Stories umsetzen müssen, da Sie sonst bei Problemen im Sprint gar nichts liefern können.

Negotiable

Negotiable bedeutet, dass die User Story immer verhandelbar sein muss. Sie ist also nie so ausspezifiziert, dass diese einmal festgelegt wird und dann in die Umsetzung kommt. Die Beschreibung ist bewusst so gewählt, dass schnell und kostengünstig neu über die User Story verhandelt werden kann und diese dann auch neu geschrieben werden kann. Während diese im Product Backlog vorhanden ist, besteht laufend die Möglichkeit diese zu verändern.

Value

Value bedeutet, dass die User Story immer einen Mehrwert besitzen muss. Eine User Story ist also nicht Mittel zum Zweck, sondern liefert einen (in sich abgeschlossenen) Mehrwert. Das hilft auch für die Bildung des Inkrements, was am Ende des Sprints zur Verfügung stehen muss. Das berücksichtigen Sie schon bei den Sprint Planung.

Estimation

Estimated bedeutet, dass die User Story eine Schätzung benötigt. Auch wenn sich die Story Points vielerorts durchgesetzt haben, sind diese nach dem Scrum Guide keine Pflicht.

Size

Size bedeutet, dass die User Story die richtige Größe besitzen muss. Sie passt also in einen Sprint. Alles was nicht in einen Sprint passt, ist erstmal ein Epic und muss dann weiter zerteilt werden. Das kann im Backlog Refinement durchgeführt werden.

Test

Eine gute User Story ist testbar. Das bedeutet, dass diese User Story von einem Tester, Endanwender oder weiteren Stakeholdern getestet werden kann. Dazu gibt es in der Regel Akzeptanzkriterien aus Benutzersicht, damit ein Testen auch möglich ist. Zudem kann der Product Owner so seine Erwartungshaltung an diese User Story ausdrücken.

Zusammenfassung für die INVEST Kriterien einer User Story

Vergleich Product Backlog Items und User Story

Ein Product Backlog Item muss keine User Story sein!

Wenn du User Stories in deinem Product Backlog nutzt, dann sind das deine Product Backlog Items. Aber ein Product Backlog Item, muss keine User Story sein. Schauen wir uns dazu kurz den Vergleich einmal genauer an.

Abgrenzung zu Epics

Der Ablauf der Erstellung aus User Story Sicht

In diesem Abschnitt zeige ich dir, wie der Lebensweg einer solchen User Story in der Regel ist. Dabei gehen wir einen exemplarischen Ablauf durch und betrachten diesen aus Sicht des Prozesses und der User Story.

Das Product Backlog

Eine User Story entsteht sehr nah am oder gleich im Product Backlog und das meistens bei einer der beiden Aktionen:

Im Product Backlog befindet sich die User Story gemeinsam mit allen anderen erstellen User Stories. Und natürlich auch allen denen, die es noch werden wollen. Alle Anforderungen, die das Produkt betreffen, gehen über diese einzige Anforderungsliste. Während des Lebenszyklusses befindet sich die User Story in diesem Product Backlog mit allen anderen Anforderungen.

Product Backlog Refinement

In dieser entwicklungsbegleitenden Tätigkeit unterzieht sich die User Story mehrerer Bearbeitungszyklen. Und das so lange, bis die User Story von allen Beteiligten verstanden und dann fertig für das Sprint Planning ist. Damit kannst du auch keine Epics in der Planung haben, da diese schlicht die falsche Größe besitzen.

Die Beschreibung

Innerhalb der Product Backlog Refinements finden häufiger Anpassungen in der Beschreibung der User Story statt. Das ist meistens dann der Fall, wenn...

Die Größe

In einem Product Backlog Refinement wird die User Story entweder initial geschätzt oder ggf. noch einmal neu geschätzt. Je länger die User Story in deinem Backlog liegt, desto höher ist auch die Wahrscheinlichkeit, dass du diese erneut betrachten und schätzen musst.

Die Akzeptanzkriterien

Wenn sich Änderungen ergeben haben oder die User Story das erste mal in einem Product Backlog Item vorgestellt wird, dann bekommt sie Akzeptanzkriterien. Diese drücken aus, was passieren muss, damit ein Product Owner diese Stories abnehmen kann.

Die Sprint Planung

In der Sprint Planung geht es darum, dass die User Stories für den kommenden Sprint geplant werden. Hier wird es also für die Stories spannend, denn sie sind dann sehr weit oben im Backlog und haben einen Chance bald dran zukommen.

Teil 1

Im ersten Teil der Sprint Planung steht die User Story direkt im Fokus. Es geht nämlich darum, dass das Entwicklungsteam beschreibt und angibt, wieviele dieser User Stories es gedenkt zu schaffen. 

Teil 2

Im zweiten Teil der Sprint Planung bietet die User Story einen übergreifenden Rahmen, denn es geht "nur" noch darum, wie diese konkret umgesetzt werden kann (also um das "wie").

Das Daily Scrum

Im Daily Scrum steht die User Story nicht so in dem Mittelpunkt, sondern mehre ihre "Kinder". Hier legst du in der Regel den Fokus auf die Tasks, die sich das Entwicklungsteam zur Erledigung der User Story erstellt hat. Natürlich darf auch hier stolz berichtet werden, wenn bereits eine ganze User Story bearbeitet worden ist und nun bereits fertig gestellt ist.

Das Sprint Review

Im Sprint Review ist dann der große Auftritt der User Story. Sie darf nämlich vorgestellt werden, wenn sie fertig ist. Ist der Auftritt dann rum, wird es danach auch still um die User Story.

Die Sprint Retrospektive

In der Sprint Retrospektive darf die User Story nur noch dann kurz ihr Antlitz zeigen, wenn sie Modell für eine Situation steht, die im Team betrachtet werden werden muss. In der Regel wird die User Story aber nicht mehr auftauchen.

Abhängigkeiten von User Stories

YouTube Video zu den Abhängigkeiten

Was mache ich mit Abhängigen User Stories? Diese Frage wird oft gestellt und auch hier habe ich auf meinem YouTube Kanal bereits ein Video dazu veröffentlicht. Schau es dir doch am besten mal an!

Chronologische Abhängigkeiten

Chronologische Abhängigkeiten sind im Grunde nicht schlimm. Sie treten dadurch auf, dass du irgendwann ein Inkrement entwickelt und eine bestimmte Funktonalität umgesetzt hast.

Wenn du im dritten Inkrement bist, dann ist klar, dass eine Funktionalität aus diesem Inkrement auf dem ersten und zweiten Inkrement aufbaut. So etwas meine ich mit chronologischer Abhängigkeit.

Wenn du das Cross-Refinement Board aus dem Nexus Framework kennst, dann ist das praktisch genau so etwas.

Inner-Sprint Abhängigkeiten

Wenn du User Stories im Sprint hast, die von einander abhängig sind, dann ist das nicht schön, mit der richtigen Betrachtung in der Sprint Planung kannst du dem aber entgegen wirken und gut planen. Wenn nichts unvorhergesehenes passiert, dann ist das in der Regel kein Problem.

Zusammengesetze Abhängigkeiten

Die Zusammengesetzten Abhängigkeiten wollen wir nicht. Das ist immer dann der Fall, wenn du eine Story als "Architektur" Story, als "Design" Story oder auch gerne als "Test" Story deklariert wird. Denn dann hast du nur noch eine Aneinanderreihung von User Stories, die im Grunde ein wassserfallartiges Vorgehen bedeuten.

Schätzen der User Stories

In den INVEST Kriterien haben wir schon gesehen, dass das E für Estimation steht. Die User Story (wie auch das Product Backlog Item) soll also geschätzt sein. Gesagt, getan, aber wie machen wir das nun konkret?

Aufwand

Eine Möglichkeit die User Stories zu schätzen ist der Aufwand. Das kennen wir, denn seit eh und je schätzen wir Menschen oft in Aufwand. Der Aufwand hat in der Regel einen großen Nachteil, wenn es um die Teamarbeit geht. Der Aufwand ist immer personenabhängig. Schätzt Peter, der 30 Jahre Berufserfahrung hat und die Aufgabe genau kennt, dann ist die Schätzung in Stundenanzahl sehr klein. Schätze ich die gleiche Aufgabe, die ich noch nie gesehen habe, geht meine Schätzung in die Tage hinein. Was machen wir nun, wenn wir im Team arbeiten? Ist der Aufwand jetzt groß oder klein?

Stunden

Den eben beschriebenen Aufwand können wir in unterschiedlichen Größen messen. Eine dieser Größen sind die allseits bekannten Stunden. Manche machen das auch in anderen Zeiteinheiten, im Grunde ist es egal und führt alles auf ein und das selbe zurück: die gute alte Stunde. 

Idealisierte Manntage

Idealisierte Manntage ist auch eine Größe, die gerne verwendet wird. Im Grunde ist es hier so, dass wir sagen "wenn nichts dazwischen kommt und wir einen Tag Zeit hätten uns nur auf diese Aufgabe zu konzentrieren, dann schaffen wir das". Während ich früher immer der Meinung war, es ist egal womit die Teams schätzen, solange sie die Fibonacci-Reihe nutzen, so stark ändert sich das nun gerade für mich. Idealisierte Manntage ist für mich im Grunde eine Erkenntnis, dass irgendwo etwas vorher nicht mit meiner Einstellung etwas stimmt. Nach und nach habe ich mir die bisherigen Projekte angesehen und kann oft die folgenden Punkte festmachen.

Idealisierte Sprints

Auch die Sprints, die idealisiert betrachtet werden, ist im Grunde nichts anderes als idealisierte Stunden oder Manntage nur eine Ebene höher.

Komplexität

Die Komplexität einer User Story zu schätzen ist etwas komplett anderes, als dessen Aufwand. Tatsächlich bekommen klassische Teams (gerade in großen Unternehmen, die stark vom klassischen Projektmanagement geprägt sind), es so gut wie gar nicht hin, sich vom Aufwand zu lösen. Dort wird dann zwar durchaus die Fibonnaci-Reihe verwendet, allerdings oft ohne Sinn und Verstand.

Referenzwert

Wir Menschen sind recht schlecht im Schätzen von absoluten Werten, können aber Relationen gut schätzen. Ich erinnere mich gerne noch an ein Projekt von lauter Mathematiker und Physiker, die mir alle weiß machen wollten, ich könne niemals deren Aufgaben schätzen. Ich habe die meisten User Stories nur basierend auf dem Referenzwert richtig schätzen können.

Kleiner oder größer?

Das Schöne an Referenzwerten ist, dass wir ziemlich gut schätzen können, ob ein neuer Wert größer oder kleiner ist. Oder eben genauso groß. Wenn wir das wissen, ist in den ersten beiden Fällen nur noch nötig zu entscheiden "wie viel".

Story Points

Die Story Points, wie wir sie heute kennen und bei einer User Story gerne verwenden basieren meisten auf der angepassten Fibonacci-Folge oder aber auch auf einer nicht angepassten. Damit sehen die Werte mal wie folgt aus:

Welche du nimmst ist im Grunde egal, es geht nur darum, dass mit zunehmender Größe die Abstände zwischen den Zahlen auch größer werden. Das drückt aus, dass wir mit allem was wir schätzen und was weiter in der Zukunft liegt bzw. größer ist einfach ungenauer werden.

Wie du User Stories schätzen kannst

Tipps für die Erstellung

Frage nach dem Benutzer

Wenn du die User Story erstellst, dann frage bitte immer nach dem Benutzer. Das klingt einfach, weil da natürlich <ROLLE> in dem Format der User Story steht. Trotzdem hilft es sich dazu einige Fragen zu stellen.

Ist der Grund wirklich ein Grund?

Manche User Stories brauchen einfach keinen Grund. Es ist implizit und explizit klar. Viele User Stories haben einen Grund, der nicht passend ist. Frage immer nach dem Grund - ist es wirklich ein Grund? Ist es nur eine Phrase, weil jemand ein bestimmtes Format ausfüllen muss? Ist der Grund implizit schon klar

User Story Vorlage

Meine PDF Vorlage zum Ausdrucken (analog)

Du kannst dir die User Story PDF Vorlage auch direkt hier herunterladen.

User Story Vorlage (digital)

Wenn du digitale Whiteboards nutzt, dann hilft es dir oft auch in dem Kontext mit Vorlagen und Templates zu arbeiten. Dort kannst du in der Regel so etwas wie digiatle Klebezettel verwenden.

Kopiere dir dann einfach einen Zettel als Vorlage und dann kopierst du ihn dir entsprechend oft.

Nutzt du Tools wie Jira & Co, dann findest du direkt in den Tools in der Regel Vorlagen, die du auch erstellen und verändern kannst. Da fragst du am besten den Administrator, denn je nach Unternehmen gibt es dort die unterschiedlichsten Einschränkungen.

Probleme, die du besser vermeidest

Den Kunden vergessen

Denke immer an den Kunden. Für ihn macht du die ganze Arbeit. Wenn du diesen mal nicht mehr im Blick hast, frage dich warum? Was ist gerade passiert und warum kannst du das entwickeln, ohne den Kunden zu adressieren?

Format nehmen, weil es jemand will

Das Format der User Story passt gut in einen komplexen Kontext, in dem für einen Kunden entwickelt wird. Wenn du dich erwischt, dass das Format öfters "nicht passt" und du es nur nimmst, "weil man das eben so nimmt" - probiere doch mal etwas anders aus. Ändere das Format, was ist anders, und was ist das Ergebnis?

Kein Produkt für den Kunden

Wenn du ein Produkt entwickelst und gar keinen Kunden hast, dann hilft dir die User Story auch nur bedingt weiter. Probiere da vielleicht andere Formate einmal aus.

Epics als User Stories verkaufen

Denke dran: User Stories sind keine Epics. Wenn du Epics (zu unscharf und zu groß) als User Stories verkaufst oder nutzt, dann wirst du diese nicht innhalb von Sprints schaffen. Wenn doch, dann sind deine Anforderungen bestimmt kleiner geworden und damit tatsächlich keine Epics mehr.