Zur Beschreibung von Anforderungen in agilen Software-Entwicklungsprojekten wird sehr gerne auf User Stories zurückgegriffen. Die Auftraggeber und die späteren Nutzer der Software müssen mit den Personen kommunizieren, von denen die Software realisiert wird. User Stories stellen eine Verbindung zwischen diesen beiden Parteien her: Sie sind verständlich für den Kunden, die Anwender und für die Entwickler.
Was ist bei der Erstellung von User Stories zu beachten? Drei Cs können dabei helfen: Card, Conversation, Confirmation. Die drei Cs gehen auf Ron Jeffries zurück, der sie schon 2001 in seinem Blog-Artikel Essential XP: Card, Conversation, Confirmation beschrieben hat. Noch heute gelten sie neben den INVEST-Kriterien, die wir bereits in einem vorangegangenen Blogbeitrag erläutert haben, als wichtige Grundregeln bei der Entwicklung von User Stories.
Card
User Stories sollen kurz und prägnant sein. Sie sollen in erster Linie an den Kundenwunsch erinnern und die wichtigsten Punkte, die mit dem Softwareentwicklungsteam vereinbart wurden, festhalten. Viele agile Software-Entwicklungsteams verwalten Stories und Tasks offline, z.B. in Form eines Taskboards. Die Kundenwünsche werden dann auf Karteikarten festgehalten.
Der auf der Karte verfügbare Platz sollte auch ausreichen, um dem Team klarzumachen, was mit der Umsetzung der Story erreicht werden soll. Genügt der Platz nicht, ist die Story in der Regel zu „groß“ oder wird zu umfangreich dokumentiert. Über die Card hinaus werden Informationen über die Anforderungen in persönlichen Gesprächen mit dem Team abgestimmt.
Conversation
Jede Story wird zwischen dem Kunden und dem Team mindestens einmal besprochen. Der Austausch über die Story ist erfahrungsgemäß ein sehr wichtiger Prozess. Es reicht nicht, auf einer Karte die Anforderungen festzuhalten und diese dem Team sozusagen „durch den Türschlitz“ zuzuschieben. Stories werden in der Regel sogar mehrmals besprochen, z.B. während eines Anforderungsworkshops, im Rahmen einer Schätzklausur und bei der Sprint-Planung. Die mündlichen Absprachen werden zudem manchmal durch zusätzliche Dokumente wie etwa Vorlagen in einem Projekt-Wiki oder Mockups begleitet.
Confirmation
Um nachzuweisen, dass die Stories in der gewünschten Form implementiert worden sind, werden für jede Story verbindliche Akzeptanzkriterien vereinbart: Der Kunde definiert vor Beginn der Umsetzung einer Story die zentralen Kriterien, nach denen die Abnahme der Story später erfolgen soll. Hierbei bietet sich die Implementierung von Akzeptanztests an, um die Erfüllung der Akzeptanzkriterien sicherzustellen.
Mit den drei Cs hat uns Ron Jeffries eine gute Merkhilfe für die Grundregeln einer User Story an die Hand gegeben.
An dieser Stelle einige Linktipps für die vertiefende Lektüre in Sachen User Stories:
- New to agile? Remember a user story is more than a card!
- Essential XP: Card, Conversation, Confirmation
- The Three C’s of User Stories – Just the card is not enough
- User Stories schreiben ist wie Fahrradfahren
- Buch Review: User Stories Applied von Mike Cohn
- User Stories: Anforderungen aus Nutzersicht dokumentieren
Mehr über die Creative-Commons-Lizenz erfahren
