User Stories schreiben - trau dich!

Warum tun wir uns manchmal so schwer, unsere Backlogs mit User Stories zu bestücken? Warum schrecken wir davor zurück - warum empfinden wir User Stories als unpassend, überkandidelt oder schlichtweg uninformativ? Es ist nicht lange her, da erzählte mir ein Product Owner, er sei von seinen Kollegen ausgelacht worden, als er mit User Stories ankam.

Vollzähligkeit vs. Vollständigkeit

Schauen wir uns zunächst die Heimat der User Story an: das Product Backlog. Das Product Backlog ersetzt klassische Anforderungsdokumente wie Lasten- oder Pflichtenhefte. Das Product Backlog strebt Vollzähligkeit an - es soll also alles bennenen, was zu einer erfolgreichen Auslieferung des Produktes gehört. Doch strebt es keine Vollständigkeit an - es soll nicht erschöpfend beschreiben, was zur erfolgreichen Lieferung alles zu tun ist.Diese Unterscheidung zwischen Vollzähligkeit und Vollständigkeit, sie fällt bisweilen schwer. Wenn ich Teams frage, in welche Richtung die Reise gehen soll, entsteht meist eine bunte Mischung aus groben Zielen und detaillierten Punkten. Details haben im Backlog aber nichts zu suchen. Denn die Backlog Items sind Platzhalter, Erinnerungsanker für spätere Gespräche, in denen die Punkte dann, jeweils für die nächsten Sprints, genauer unter die Lupe genommen werden.Eine gute Möglichkeit, die richtige Flughöhe für das Product Backlog zu finden, ist das Schreiben von User Stories. Sie beschreiben die Produkteigenschaften aus der Sicht des Benutzers. Ihre Form ist recht simpel:Als (Benutzer) möchte ich (Funktionalität), um (Nutzen).Ein Beispiel: Als junger, angehender ScrumMaster, möchte ich in diesem Blog Inspiration, Wissen und Austausch zum Schreiben von User Stories finden, damit ich meine Begeisterung an andere weiter geben kann.Unser Kollege Jürgen Margetich sagt, dass in User Stories Hypothesen stecken. Wir behaupten zu wissen, für wen und wozu wir etwas entwickeln. Ich behaupte, dass es junge, angehende ScrumMaster gibt, die aus dem Lesen dieses Blogbeitrages andere für ihre Ideen gewinnen können.Zugegeben: Manchmal ist es nicht leicht, im Scrum-Team User Stories zu schreiben. Der User ist nicht allen klar vor Augen. Das, was gebaut wird, ist so klein oder so versteckt im System, dass es schwer fällt, darin einen Nutzen zu sehen. Manchmal sind Teams noch in der Konzeptphase, bevor sie etwas Funktionierendes bauen und dann dem Nutzer vorführen können. Das ist vor allem dann der Fall, wenn das Team noch in einer frühen Gestaltungsphase steckt - und noch gar nicht sagen kann, wie das Produkt aussehen wird. Gerade in der Hardwareentwicklung mit ihren eigenen Phasen und Laufzeiten sind Teams nicht in der Lage, am Ende einer jeden Iteration Funktionalitäten laufen zu lassen.Mein Rat: Ermuntere dein Team, trotzdem User Stories zu schreiben. Denn es kommt in erster Line gar nicht darauf an, den ultimativen Nutzen für den ultimativen User herauszuarbeiten. Es geht vielmehr darum, sich einen Weg aus dem Dickicht an alles- und zugleich nichtssagenden Anforderungen frei zu schlagen - und zu erkennen, worauf es wirklich ankommt.Praxisbeispiel: Mein aktuelles Team ist gerade dabei, die Achsen für ein neue Pumpe zu spezifizieren, um die Konstruktion beim Lieferanten in Auftrag zu geben und dann als erstes Funktionsmuster testen zu können. Bei unseren zweiwöchigen Sprints sieht eine User Story dann folgendermaßen aus:Als Achsenfertiger Bodo Seemann möchte ich verstehen, was ich bis wann zu bauen habe, damit ich ein brauchbares Fuktionsmuster innerhalb der vereinbarten Zeit liefern kann.Was haben wir durch das Formulieren von User Stories gewonnen? Was wäre anders gewesen, wenn statt der User Story nur der Hinweis: Achsen spezifizieren und bestellen gestanden hätte? Durch die Personifizierung in der User Story (Bodo Seemann) ist der Zweck der Aufgabe beschrieben: Es geht eben nicht darum, eine Spezifikation zu schreiben oder diese an Bodo Seemann zu schicken. Es geht darum, dass Bodo Seemann in die Lage versetzt wird, ein belastbares Funktionsmuster innerhalb eines vereinbarten Zeitrahmens zu bauen. Wie das geschieht - das ist Teil der Umsetzung, um die sich das Team selbstverantwortlich zu kümmern hat. Die Umsetzung hat keinen Wert an sich, sondern ist nur in Bezug auf das eigentliche Ziel relevant.Experimentierst du auch mit User Stories? Auf welche Schwierigkeiten bist du gestoßen? Hast du vielleicht Beispiele für gelungene, unkoventionelle User Stories? Ich bin gespannt!LiteraturMike Cohn: User Stories Applied.Sven Winkler: Wie schreibe ich eine User Story oder anders gefragt: Was nützt mir der Nebel?