User Storys – So schreibt man Geschichte(n)

Eine User Story ist in der agilen Arbeitswelt eine kurze, einfach formulierte Beschreibung einer gewünschten Funktionalität aus Sicht des Endbenutzers oder Kunden. Sie folgt meist dem Muster: „Als [Rolle] möchte ich [Funktion], damit ich [Nutzen]“. User Stories helfen Teams, sich auf den tatsächlichen Mehrwert für die Nutzer zu konzentrieren und fördern die Kommunikation zwischen allen Projektbeteiligten.

So ist die Vorstellung, dass User Storys gewöhnliche Software-Systemanforderungen sind, noch weit verbreitet. Doch dies ist nur die halbe Wahrheit. Verständlich, User Storys transportieren Anforderungen, aber in erster Hinsicht sind sie ein Kommunikationsmedium. Basierend auf unserer Erfahrung mit mehreren Projekten haben sich einige bewährte Praktiken herauskristallisiert.

User Storys beschreiben die Umsetzung einer Funktion aus der Sicht des Anwenders. Sie fokussieren sich nicht auf technische Lösungen wie Details zum Frontend, Backend oder der Datenbank, sondern auf die erlebbaren Features für den Kunden. Eine gängige Vorlage für User Storys folgt diesem Schema:

„Als <Rolle> möchte ich <Anforderung>, damit <Zweck> erreicht wird“

Insbesondere der zweite Satzteil „…, damit …“ birgt ein großes Potenzial für Entwickler und Produktverantwortliche. Ein alltägliches Beispiel verdeutlicht dies:

Frieda beauftragt eine Firma, ihr Gartengrundstück einzugrenzen. Die Firma baut ihr eine 2-Meter hohe Mauer auf, dass sie sich auch wirklich sicher fühlt. Zur großen Überraschung der Firma ist die Kundin überhaupt nicht zufrieden. Es ging ihr sehr wohl um Sicherheit, allerdings um die Sicherheit ihres Dackels „Fifi“, der regelmäßig aus dem Garten entwischt. Bei anschließender Analyse wird festgestellt, dass ein 70 cm hoher Zaun ausgereicht hätte.

Entwickler können ähnlich ungeeignete Lösungen entwickeln, wenn der Zweck nicht klar ist. Dies kann vermieden werden, wenn der Zweck der User Story direkt angegeben wird. Das Team kann daraufhin genauer verstehen, was gewünscht ist und durch Vorschläge den Produkt-Verantwortlichen bei besseren, einfacheren und nachhaltigeren Ergebnissen unterstützen.

Du möchtest Deinen agilen Prozess überarbeiten?

Wir teilen gern unsere umfangreiche Erfahrung mit Dir. Sprich uns gern darauf an!

Buche einen Termin online oder rufe uns an.

Eine User-Story soll in einem Refinement-Workshop so weit von dem Entwickler Team verstanden werden, dass sie geschätzt und umgesetzt werden kann. Dies bedeutet auch, dass nicht jedes Detail vorab geklärt sein muss. Die User Story dient als Kommunikationsmedium zur Findung kreativer Lösungen. Offene Fragen können während des Workshops geklärt und idealerweise in der User-Story ergänzt werden. Das Schreiben und Ergänzen ist nicht nur Aufgabe des Product Owners, sondern kann von jedem im Team übernommen werden.

Auch wenn User Storys Anforderungen transportieren, gibt es keinen finalen Zustand, an dem sie als fertig spezifiziert gelten. Dies wäre eine Reise in Richtung Wasserfall-Modell, was wir in der agilen Welt iterativ angehen wollen. In Absprache mit dem Entwickler dürfen weitere Informationen oder Anforderungsänderungen, in der Story ergänzt oder verändert werden, auch wenn sie bereits in einem Sprint enthalten ist.

Wie bitte? Ja, eine User Story darf auch in der Implementierung noch angereichert oder verändert werden, sofern das Entwickler-Team zustimmt und das Sprint-Ziel nicht gefährdet wird. Damit wird das agile Prinzip lebendig: „Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden“.

User Storys sind die Arbeitseinheiten für Entwickler innerhalb agiler Frameworks. Sie bestehen aus mehr als nur dem initialen Satz „Als User möchte ich …“. Sie enthalten relevante Informationen zur Umsetzung der Funktionalität, die von Team zu Team variieren können. Typische Abschnitte und Angaben sind:

• Akzeptanzkriterien: Wann ist die User Story umgesetzt?
• Schnittstellen: Sind andere Systeme betroffen?
• Dokumentation: Gibt es Vorgaben hinsichtlich der Dokumentation?
• Testing: Gibt es Vorgaben hinsichtlich spezieller Testfälle?
• Qualitätsanforderungen: Müssen gesetzliche Vorgaben wie z.B. die DSGVO berücksichtigt werden?
• Weitere Informationen: z. B. Datenmodelle, Grafiken, Entwürfe

Wer ist eigentlich pep.digital?

Lernen Sie die Köpfe hinter pep.digital kennen und erfahren Sie, wer wir sind, wie wir arbeiten, denken und ticken.

Mehr über pep.digital lesen

Um das Beispiel von oben nochmals aufzugreifen, so könnte eine optimale User Story für Frieda folgendermaßen aussehen:

Als Hundebesitzerin von Fifi möchte ich eine Begrenzung um meinen Garten, damit Fifi nicht mehr weglaufen kann.

Akzeptanzkriterium
– Der Garten hat an den Außenseiten eine Begrenzung
– Die Begrenzung ist so hoch, dass Fifi nicht darüber springen kann
– Die Begrenzung lässt Grashüpfer passieren
– Die Baurechtsvorschriften wurden eingehalten

Testing
User Acceptance Test: Fifi ist nachts draußen geblieben und am nächsten Morgen noch im Garten.

Infos
Grundstücksplan.jpg

Hinweise
Der Nachbarzaun kann mitgenutzt werden

Eine optimale User Story für Frieda

Wenn ein Team eine User Story liest, weiß es, was entwickelt wird, warum es entwickelt wird und welchen Wert (engl. (Business-)Value) es damit schafft.

User Storys sind mehr als nur Anforderungen – sie sind die perfekte Geschichte, die ein agiles Team zusammenführt und auf ein gemeinsames Ziel hinarbeiten lässt.

Welche Hacks für gute User Storys haben Euch vorangebracht?