Immer mehr Unternehmen und Entwicklungsteams gehen zur agilen Softwareentwicklung über. Während die IT-Abteilungen in der Regel mit den Basics der agilen Methodik vertraut sind, stellt diese die Anforderungs- und Produktmanager sowie neue Product Owner häufig vor grössere Herausforderungen. Wenn man zum ersten Mal ins Schwimmbad springt, taucht man ja auch nicht gleich 50 Meter durch. Heisst, aller Anfang ist schwer, aber es lässt sich leicht lernen – und – ich bin der Meinung, dass jeder User Stories schreiben kann.
Die drei Bestandteile der User Story
Eine User Story beschreibt ein Stück Funktionalität aus der Sicht des Benutzersund besteht aus drei Bestandteilen:
- Name
- Beschreibung
- Akzeptanzkriterien
Folgende Schritte sollen helfen gute User Stories zu schreiben:
1. Als [Benutzerrolle] will ich [Ziel/Aktion], so dass ich [Grund für das Ziel]
An einem Beispiel sieht das folgendermaßen aus:
Name: Geld am Automaten abheben
Beschreibung: Als ein [Kontoinhaber] will ich Geld vom Automaten abheben, so dass ich außerhalb der Öffnungszeiten Geld bekomme.
Aktzeptanzkriterien:
1. Szenario: Konto verfügt über ausreichend Geld:
Vorausgesetz, dass ausreichend Geld auf dem Konto des Kontoinhabers ist, die Karte gültig ist und der Automat mit genügend Geld gefüllt sind, gibt der Automat die angeforderte Geldmenge aus und die EC-Karte zurück.
2. Szenario: Karte ist ungültig
Vorausgesetzt, dass die Karte ungültig ist, wird diese vom Automaten einbehalten, unabhängig wieviel der Kontoinhaber abheben möchte. Der Automat gibt den Grund im Display an.
…..
2. Akzeptanzkriterien
Die Akzeptanzkriterien sind zwingender Bestandteil von User Stories und vermutlich der schwierigere Teil. Sie helfen bei der Fokussierung auf die konkrete Beschreibung, schaffen eine höhere Verbindlichkeit, machen die Stories in der Regel überhaupt erst richtig messbar für die Entwickler und sparen schlicht Zeit in der Kommunikation.
3. Nutzung von Cards
Es hat sich bewährt User Stories auf Karteikarten zu schreiben. Das hat mehrere Vorteile. Die Größe zwingt bereits zu einer kurzen Fassung und anschliessend lassen sich die Stories sehr schön an der Metaplanwand organisieren und besprechen.
4. Detaillierung von User Stories
In der Regel macht es Sinn, User Stories immer zu sammeln und erst wenn die Realisierung ansteht detailliert auszuformulieren. Dabei kann eine übergeordnete User Story, auch Epic genannt, mehrere User Stories ergeben.
5. Woran merke ich, dass die User Stories nicht gut sind?
- Die User Story ist sehr lang (mehrere Sätze).
Die Story ist vermutlich teilbar und wird mit der Länge nicht eindeutiger.
- Die User Story bezieht sich auf mehrere Funktionen.
User Stories müssen in die kleinste teilbare Anforderungsbeschreibung unterteilt werden.
- Die Story erzeugt Diskussionen und Fragen.
Die Story ist nicht konkret und verständlich genug.
- Die Story beinhaltet technische Lösungen.
User Stories sind grundsätzlich lösungsneutral formuliert.
6. Die INVEST-Kriterien
Eine gute User-Story sollte immer die folgenden INVEST-Kriterien erfüllen:
- Indipendent: Die Story muss unabhängig von anderen Stories sein und darf nicht die Umsetzung einer anderen Story voraussetzen.
- Negotiable: User Stories sind nicht in Stein gemeißelt (wie z. B. Anforderungen bei klassischen Pflichtenheften), sondern dienen mit ihrer Beschreibung dem engeren Dialog zwischen Anforderern bzw. Kunde und den Entwicklern.
- Valuable: Die Stories sollten einen erkennbaren Mehrwert liefern. Anonsten können sie auch verworfen werden.
- Estimatable: Eine Story muss so überschaubar sein, dass die Entwickler die Umsetzung der Anforderung beschätzen können. Zudem müssen die Entwickler natürlich über die entsprechenden fachlichen und technischen Kompetenzen verfügen.
- Small: Über den konkreten Umfang von User Stories muss letztlich das Team entscheiden. Stories können „zu groß“ und „zu klein“ sein. Als grobe Regel gilt: Die komplette Umsetzung einer Story soll mindestens einen halben Personentag und maximal zehn Personentage erfordern.
- Testable: Die Tests bilden den Maßstab dafür, ob eine Story erfolgreich abgeschlossen wurde oder nicht. Daher muss die Testbarkeit zwingend gewährleistet sein.
Letzte Kommentare