Eine User Story ist eine spezifische Form der Anforderungsdokumentation. Dabei liegt der Fokus auf der Perspektive der Anwender, dereren Probleme, Bedürfnisse und Anreize in ein bis zwei prägnanten Sätzen niedergeschrieben werden. Ergänzt wird die User Story um Akzeptanzkriterien, die an eine zufriedenstellende Lösung gestellt werden. User Storys haben ihren Ursprung im Extreme Programming, das u.a. von Kent Beck in den 1990er Jahren erfunden wurde.
Wir werden oft gefragt, wie die perfekte User Story aussieht. Die vielleicht überraschende Antwort: Bei User Stories kommt es überhaupt nicht auf die Form an. Wichtiger ist, was man damit tut. Und das steckt ebenfalls im Namen: User Storys sind ein Platzhalter für eine Konversation über die Bedürfnisse der Nutzer und mögliche Lösungen. Erkenntnisse, die aus diesen Gesprächen herrühren, werden auf Karten festgehalten.
Entsprechend können User Storys völlig frei formuliert werden. Häufig wird jedoch ein bestimmtes Format genutzt, das von Mitarbeitern der Firma Connextra definiert wurde: Als *Rolle* möchte ich *Funktion*, um *Nutzen zu erhalten*. Wir empfehlen übrigens mit dem Wofür? zu beginnen, da “Als Rolle möchte ich Funktion” grammatikalisch völlig in Ordnung ist und dazu einlädt, das Wofür? wegzulassen. “Um Nutzen zu erhalten” ergibt hingegen für sich allein genommen wenig Sinn.
Neben der namensgebenden Beschreibung des Problems aus Nutzersicht enthalten User Storys für gewöhnlich eine prägnante Überschrift; das macht Unterhaltungen über die User Story wesentlich einfacher.
Weitere Elemente können sein:
Akzeptanzkriterien,
das Datum, an dem die Karte erstellt wurde,
die Priorität,
eine Größen-Schätzung,
ggf. das Datum, an dem die Karte in Bearbeitung genommen wurde
und ggf. das Datum, an dem die Arbeit an der User Story beendet wurde.
Wie werden User Storys im Anforderungsprozess eingesetzt?
Fundstück aus dem Internet (Quelle leider unbekannt)
User Storys sind allen voran ein Werkzeug, um mit Anforder:innen, Expert:innen und interessierten Stakeholdern ins Gespräch zu kommen. Dabei gilt: Je nach Zielgruppe werden andere Aspekte im Fokus stehen. Die User Story hilt dabei, den Blick auf die Nutzer nicht zu verlieren.
Wir empfehlen Product Ownern und Produktmanagern daher, User Storys nicht alleine auszuarbeiten und besonders ausführlich für das Entwicklungsteam zu spezifizieren mit dem Ziel Nachfragen auf ein Minimum zu beschränken. Jeff Patton, Autor des Buches “User Story Mapping”, erinnert uns stetig daran: Geteilte Dokumente schaffen kein gemeinsames Verständnis! Schriftlich dokumentierte Anforderungen, die auch nur die geringste Komplexität aufweisen, werden immer Interpretationsspielraum aufweisen. Zudem wecken die “nackten Fakten” kaum Begeisterung bei den Beteiligten. Der Mensch liebt Geschichten, denn diese aktivieren das limbische System im Gehirn. Geschichten sind greifbar, erschaffen Muster und lassen uns kreativ werden.
Nutzen Sie daher die Kreativität Ihres Teams und spannen Sie den Lösungsraum weit auf, in dem Sie User Storys ohne vorgefertigte Spezifikation und Akzeptanzkritieren zur gemeinsamen Erkundung der Lösungsmöglichkeiten zur Diskussion stellen.
Ron Jeffries nennt dies die 3C Praktik. Die 3Cs stehen für:
Card – Schreiben Sie eine Anforderung kurz und knapp (z.B. in Form des Connextra-Template “Als Rolle möchte ich Funktion, um Nutzen zu erhalten”) auf eine Karte.
Conversation – Sprechen Sie mit Ihrem Team, Stakeholdern und Experten über diese Anforderung. Explorieren Sie gemeinsam verschiedene Nutzerperspektiven und welche Lösungsmöglichkeiten es gibt.
Confirmation – Halten Sie Akzeptanzkriterien fest, die Sie an die Lösung stellen.
Was ist die perfekte Größe einer User Story?
Wir erleben häufig, dass User Storys in eine Art Hierarchie eingebettet werden. So bilden z.B. Epen (engl. Epics) eine thematische Klammer über mehrere User Storys, die sich widerum in Tasks und Subtasks zerlegen lassen. Tatsächlich steckt aber hinter all diesen unterschiedlichen Begrifflichkeiten wieder User Storys. Jeff Patton vergleicht User Storys mit Steinen. Wenn ich mit einem Hammer darauf schlage, zersplittern diese in kleinere Teile, die aber ebenfalls Steine sind.
Der Wunsch nach verschieden großen User Storys basiert auf den unterschiedlichen Bedürfnissen der beteiligten Stakeholder:
Produktmanager und fachliche Anforderer wollen User Storys so groß schneiden, dass ein in sich abgeschlossener fachlicher Nutzen darin erkennbar wird.
Entwickler und technische Experten wollen User Storys hingegen so klein schneiden, dass in sich geschlossene, kleine Liefereinheiten daraus werden.
Es gilt im Gespräch hier sinnvolle Liefereinheiten und deren fachliche Klammern zu indentifizieren. Für beides ist die User Story ein geeigneter Container. (Allerdings sei hier auch erwähnt, dass nicht jede Anforderung in ihrem Product Backlog in Form einer User Story formuliert werden muss und sollte! Nutzen Sie dieses Werkzeug, wo es Ihnen sinnhaft erscheint und einen Mehrwert bietet.)
Die unterschiedlichen Flughöhen und Ausbaustufen von User Storys können Sie z.B. mittels des User Story Mappings erkunden und detaillieren.
