In User Stories werden Wünsche oder Anforderungen der Anwender einer Dienstleistung bzw. eines Produktes formuliert. Sie bestehen aus nur wenigen Sätzen. User Stories sind kurz, knapp und verständlich, aus Anwendersicht jedoch spezifisch und detailliert.
Notation
User Stories beinhalten immer eine Rolle (Wer fordert etwas?), eine Funktion (Was wird gewünscht?) und einen Nutzen (Warum / wozu will man etwas?). Wir beschreiben Wer, Was und Warum. Ganz einfach, oder? Hier ein paar Beispiele:
«Als Mitarbeiter am Empfang will ich nach Dateinamen filtern können, um schnell die richtigen Dokumente zu finden, wenn ein Besucher vor mir steht.»
«Als Sportlerin, die viermal in der Woche trainiert, will ich meine Trainingssachen deponieren können, damit ich direkt nach der Arbeit ohne Gepäck ins Training kommen kann.»
Schätzen
Die fertig formulierten Stories können im Anschluss geschätzt werden. Wie viel Aufwand generiert uns diese Anforderung? Oft verwendet man dazu Story Points oder T-Shirt-Sizes (S/M/L/XL) mit einer Referenz. So hat jedes Teammitglied die gleiche Vorstellung, wie gross beispielsweise ein M ist. Jedes Teammitglied gibt gleichzeitig mit allen anderen eine Schätzung ab (z.B. mit Planning Poker Karten). Ist man sich nicht einig, werden der tiefste und der höchste Wert erläutert. Dies hilft für das gemeinsame Verständnis und ist zugleich auch ein Know-How Transfer. Das Team einigt sich dann auf eine Aufwandschätzung.
Nicht nur die Grösse (Umsetzungsaufwand), sondern auch die Priorität kann bestimmt werden. Ein grosser Vorteil von Userstories ist, dass «das Warum» ersichtlich wird. So kann der Kunden-Nutzen und Mehrwert schnell erkannt werden. Was müssen wir zwingend zu Beginn haben, was können wir ev. später machen? A, B, C oder Muss/Kann Priorisierungen reichen fürs Erste. Noch effizienter ist die Priorisierung direkt im Backlog.
Akzeptanzkriterien
Wie können wir nach der Umsetzung prüfen, ob der Kunde / die Kundin das «Richtige” erhalten hat? Genau, es braucht vorgängig festgelegte (Abnahme-)Kriterien, wann etwas fertig (richtig) ist oder nicht. Wir vermerken diese auch gerne direkt bei der Userstory (in Jira im Detailbeschrieb). Für die Story der Sportlerin oben könnten wir uns folgende Akzeptanzkriterien vorstellen:
- Der Bereich soll Platz für folgende Sachen bieten: 1 Paar Turnschuhe, Trainingskleider, Handtuch, Necessaire, kleine Handtasche (min. 50x50x70cm).
- Der Bereich soll durch die Nutzerin abgeschlossen werden können (Wertsachen).
- Eine Kleiderstange mit zwei Kleiderbügeln soll vorhanden sein (optional).
Mit diesen Kriterien geben wir nicht vor, wie die Lösung zu bauen ist (z.B. «Garderobenfächli»). Sondern nur, was unsere Anforderungen mit Fokus auf das Produkt / die Lösung sind. In diesem Beispiel wäre also eine eigene, abschliessbare Garderobe auch möglich und nicht nur ein kleines Fächli.
Tipps und Tricks
- Denke an alle potenziellen Rollen, die das Produkt / die Lösung künftig nutzen könnten (nicht nur heutige Kunden).
- Sei so präzis wie möglich und lass so viel Umsetzungs-Spielraum wie nötig.
- Für Anforderungen an eine Software kann es Sinn machen, die User Stories mit der Given-When-Then Notation zu ergänzen. Das hilft für das Abbilden und Durchführen der Testfälle und deren Automatisierung.
Wie formulierst du für deine Vorhaben Anforderungen? Welche Tools und Methoden haben sich bewährt, welche weniger? Ich freue mich auf deine Gedanken zum Thema unten in den Kommentaren. Weiterführend kannst du dir unsere erfolgreichen IT Projekte ansehen und alles rund um Agilität lesen.
