In der Welt agiler Projekte sind sie unentbehrlich. User Storys. Die Definition variiert, und das Spektrum der Interpretationen ist breit gefächert. Der Scrum-Guide zum Beispiel spricht lediglich von „Arbeit, die zu erledigen ist“, ohne eine spezifische Technik wie User Storys vorzugeben.
So ist die Vorstellung, dass User Storys gewöhnliche Software-Systemanforderungen sind, noch weitverbreitet. 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 als Anforderungs-Beschreibungen
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.
User Storys als Diskussionsgrundlage
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 als Arbeitseinheiten
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
Beispiel
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 |
Resümee
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?
Quellen:
https://www.atlassian.com/de/agile/project-management/user-stories
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf
https://agilemanifesto.org/iso/de/principles.html