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:
Zielorientierung bei einer User Story
Als Verkehrsteilnehmer möchte ich schnell von A nach B gelangen, um möglichst wenig Wegezeit zu erzeugen.
Lösungsorientierung bei einer User Story
Als Autofahrer möchte ich mit dem Auto von A nach B gelangen, um mein Ziel zu erreichen.
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
Du hast eben also die sogenannten INVEST Kriterien kennengelernt. Betrachtest du sie noch etwas genauer, dann wirst du erkennen, dass dort bereits viel für agile, interative und inkrementelle Entwicklung als Grundstein gelegt ist.
Vergleich Product Backlog Items und User Story
In diesem Abschnitt möchte ich zum Abschuss noch einmal den Fokus auf den Scrum Guide legen, der Product Backlog Items beschreibt und dann die agile Praktik der User Story, die nicht im Scrum Guide steht.
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
Oben bei dem Size aus dem Invest Kriterium habe ich Epics bereits einmal kurz erwähnt. Dieser Begriff wird oft unterschiedlich verstanden. Zum einen ist erstmal alles, was größer ist als eine User Story ein Epic. Das war es im Grunde auch schon. Epics werden allerdings auch in Tools und anderen Frameworks als andere Typ aufgefasst. Also alle Anforderungen, die größer und vielleicht auch abstrakter sind, werden dann als eigener Typ geführt, der letztendlich auch wieder herunter gebrochen wird.
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
Im Product Backlog Refinement findet die Bearbeitung der User Story statt. Das ist wichtig und elementar für jede Scrum Implementierung. Wenn du das Refinement bei deiner Scrum Einführung nicht richtig berücksichtigst und gut implementierst, fällt es dir spätestens bei einer Scrum Skalierung auf die Füße.
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
In meinem Artikel zum agilen Schätzen habe ich dir die entsprechenden Schätzmethoden einmal aufgeführt. Schau doch dort gerne mal vorbei!
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.
