User Stories sollten nach einem bestimmten Muster erstellen und im Product Backlog verwaltet werden. Wenn man User Stories immer nach dem gleichen Muster gestaltet, erhöht man die Chance im Team ein gemeinsames Verständnis für die Aufgabe zu erlangen.
Jede User Story sollte die folgenden informellen Aspekte erfüllen:
- Wer wird diese Feature in erster Konsequnz nutzen?
- Gibt es noch weitere Nutzer?
- Was muss im Endeffekt getan werden?
- Welchen „geschäftlichen“ nutzen hat das Feature?
- Mit welchen anderen Features hängt es ggf. zusammen?
Je nachdem wie das Team User Stories definieren möchte, könnte man noch die folgenden Informationen ebenfalls hinzufügen:
- Wie wird das Feature demonstriert?
- Wie wird das Feature getestet?
Um alle diese Informationen in eine User Story aufnehmen zu können, sollte man jede User Story nach einer gewissen Strutkur aufbauen. Eine der meisten verwendeten Vorlagen ist gestaltet sich nach dem folgenden Muster:
Als ein Administrator von der Benutzerverwaltung, möchte ich über die Anzeigeliste der Benutzerkonten der Lage sein, Benutzerkonten vollständig zu administrieren. D.h. ich möchte Benutzerkonten anlegen, bearbeiten und löschen können. Jedes Benutzerkonto muss die folgenden Informationen haben:
- Benutzername (Mindestens 8 Zeichen, der Benutzername darft nicht die eMail Adresse sein)
- Anrede (Herr oder Frau als Auswahlbox)
- Vollständiger Name (Vor- und Nachname getrennt)
- Adresse (Strasse, Hausnummer, Postleitzahl und Ort getrennt)
- eMail Adresse (Eingabe auf „@“ und „.“ zu prüfen)
- Passwort (Mindestens 6 Zeichen, bestehend aus min. einem Großbuchstaben und min. 2 Sonderzeichen)
Die Möglichkeit des Anlegens, Editierens und Löschens sollen in einzelnen Dialogen realisert werden. Ich benötige diese Feature, um Benutzerkonten losglöst vom Registrierungsprozess verwalten zu können.
Diese Beispiel User Story beantwortet alle Fragen aus der obigen Anforderungsliste. Überprüfen wir diese Festellung an Hand der gestellten Fragen:
- Wer wird diese Feature in erster Konsequnz nutzen? Administratoren
- Gibt es noch weitere Nutzer? Nein
- Was muss im Endeffekt getan werden? Benutzerkonten Bearbeitunsfunktionen auf der Liste der Benutzerkonten durchzuführen
- Welchen „geschäftlichen“ nutzen hat das Feature? Eigenständige Verwaltung der Benutzerkonten durch den Administrator
- Mit welchen anderen Features hängt es ggf. zusammen? Mit dem Registrierungsprozess und der Übersichtsliste der Benutzerkonten
Man findet in User Stories explizite und impliziete Anforderungen. Ich fokusiere das Teams gerne auf die implizieten Anforderungen und spreche diese in den Scrum Meetings durch. Das ist wichtig da impliziete Anforderungen immer durch die Wahrnehmung jedes Team Mitgliedes ggf. anders Wahrgenommen werden können als explizite Features. Um das Risiko eines Missverständnisses zu verringern, muss man als Scrum Master darauf achten, dass die Diskussion innerhalb der Gruppe die Features von allen Seiten betrachtet. Ich versuche daher gerne ähnliche Umsetzungen in anderen Produkten als Beispiel zu zeigen. Zu dieser Anforderung an eine Benutzerverwaltung würde ich z.B. die Benutzerverwaltung von WordPress zeigen, um die Diskussion über die User Story zu unterstüzen.
Wichtig ist es in den Grooming Sessions und in der Sprint Planung muss das Team die User Story mit Informationen zur Umsetzung anreíchern. Das geschieht meistens automatisch innerhalb der Diskussion. Während der Diskussion enstehen meistens Fragen zu den einzelnen User Stories und diese Fragen müssen geklärt und an die betreffende Stelle in der User Story geschrieben werden. Im obigen Beispiel erkennt man diese zusätzlichen Informationen aus der Disskussion innerhalb der Klammern.
User Stories sind „Lebendegebilde“ und werden von Meeting zu Meeting verändert, erweitert oder neu aufgeteilt. Sollte das Team feststellen, dass eine User Story eigentlich zu groß und damit zu unverständlich ist, Muss man versuchen Teile der User Story in eigene User Stories herunter zu brechen und neu zu definieren. Im obigen Beispiel könnte man zum Beispiel das Anlegen, oder das Editieren in eigene User Story auslagern.
Das gemeinsame Verständnis innerhalb des Teams für den Inhalt einer User Story sehr wichtig. Für manche Teams kann es hilfreich sein eine Definition of Ready DOR zu definieren. Die DOR defniert welche Kriterien eine User Story erfüllen muss, um als READY zur Umsetzung zu betrachten. Das hilft dem Product Owner bereits frühzeitig zu erkennen, welche Informationen für eine User Story bereitgestellt werden müssen und erleichtert in der Sprint Planung die Auswahl von einzelnen User Stories für den angehenden Sprint.