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. Und sie sind auf den eigentlichen Nutzen, der mit der Realisierung der User Story erzielt werden soll, ausgerichtet.

Der Aufbau einer User Story

User Stories folgen einem festen Schema, das folgendermaßen aufgebaut ist:

Als (Benutzertyp) möchte ich (Anforderung), um (Kundennutzen).

Beispiele für User Stories aus der Entwicklung von TwentyFeet

Für die Entwicklung des Egotracking-Dienstes TwentyFeet implementieren wir eine strikte Durchführung von Scrum und User Stories. Hier sind ein paar Beispiele mit Kommentaren:

Story: Lesson learned festhalten können

Als (Benutzer) möchte ich (meine Erklärungen für die außergewöhnlichen Entwicklungen, die mir vom ActivityStream mitgeteilt werden, hinterlegen können), um (ein besseres Verständnis für die Ursachen der Veränderungen zu erhalten).

Akzeptanzkriterien:

• Auf der DetailPage von ActivityStream-Einträgen gibt es ein Eingabefeld für eine "Lesson learned" / "Meine Erklärung" (Überschrift des Blocks). Das Feld ist 118 Zeichen lang. Mehr kann nicht eingegeben werden.
• Es gibt einen kleinen Zeichenzähler, der dem Nutzer die restliche Zeichenzahl darstellt.
• Nach Eingabe kann der Nutzer über den Button "Save lesson learned" / "Meine Erklärung speichern" abspeichern und bekommt seinen Eintrag angezeigt.
• Der Eintrag kann editiert werden.

Diese Anforderungen werden dann mit einem Entwickler und Designer zusammen
durchgesprochen, woraufhin ein Design gemacht wird. Dieses kann dann noch
einmal besprochen werden, bevor es umgesetzt wird.

Story MySpace: Autorisierung mittels oAuth

Als (Benutzer) möchte ich (mittels oAuth mein mySpace-Konto bei TwentyFeet hinterlegen können), um (Auswertungen darüber zu erhalten).

Akzeptanzkriterien:

• Ich kann mit meinem oAuth-Zugang immer nur mein eigenes mySpace-Konto abrufen (keine fremden Konten).
• Es gibt nur die Option oAuth, eine Eingabe eines Benutzernamen funktioniert bei MySpace nicht.
• Die Texte werden von Twitter übernommen.

Diese Story fällt besonders kurz aus, da schon häufiger eine ähnliche Anforderung
im Laufe des Projekts umgesetzt wurde. Dem Team reichen daher grobe Rahmenbedingungen,
um die Anforderung zu beschätzen und umzusetzen.

Story: Twitter Follower Detailinfo

Als (Benutzer) möchte ich (detaillierte Infos zu den Veränderungen meiner Twitter-Follower haben), um (mein weiteres Verhalten daran auszurichten).

Akzeptanzkriterien:

• Bei Veränderungen der Follower-Zahl werden auf der DetailPage neue Follower und entfolgte User angezeigt.
• Der Name der User wird mit einem ist ein Link auf ihr Profil bei Twitter versehen.

Vorbelegung der Zeitzone

Als (Benutzer) möchte ich (bei meiner Registrierung bei TwentyFeet im Hintergrund meine Zeitzone vorausgewählt bekommen), um (mir die Zeit für die Auswahl zu sparen). Über die Personal Settings kann ich sie ggf. später anpassen.

• Wir holen über die IP-Adresse des Anwenders bereits die Info ein, aus welcher Zeitzone der User kommt, und wählen diese im Hintergrund (nicht für den Anwender sichtbar) aus.
• Der User kann die Zeitzone bei Bedarf anpassen.

Das Team bespricht dann die einzelnen Tasks, die zur Umsetzung notwendig sind:

Wichtig ist, dass sich im Laufe des Projekts eine gemeinsame Sprache herausbildet. Das wird zwei, drei Sprints dauern, dann kann dank der gemeinsamen Sprache im Projekt auch der Detaillierungsgrad der Stories abnehmen, da ein gemeinsames Verständnis vorhanden ist.

Die INVEST-Kriterien

Eine gute User Story erfüllt die sog. INVEST-Kriterien. INVEST steht dabei für:

• Indipendent: Eine Story ist unabhängig von anderen Stories. Eine Story darf nicht davon abhängen, dass zuerst eine andere Story umgesetzt werden muss.
• Negotiable: User Stories sind kein geschriebenes Gesetz. Kunden und Entwickler besprechen und präzisieren sie gemeinsam. Während der Kunde also die Funktionalität kurz und grob beschreibt, werden die Details mit den Entwicklern zusammen ausgearbeitet.
• Valuable: Die Stories sollten einen erkennbaren Mehrwert liefern. Ansonsten gibt es keinen Grund, sie vorzuhalten. Der beste Weg zu wertvollen Stories ist der, sie vom Nutzer selbst schreiben zu lassen.
• 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.

Die drei Cs einer User Story

Drei Cs helfen beim Verständnis von User Stories: 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.

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 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 manchmal begleitet durch zusätzliche Dokumente wie etwa Vorlagen in einem Projekt-Wiki oder Mockups.

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.

Linktipps zu 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
• User Stories on agile-software-development.com
• Personas geben Zielgruppen Gesichter
• Writing Good User Stories
• The Easy Way to Writing Good User Stories
• Why & How to write User Stories
• Do's and Don'ts for User Stories, Use Cases, Scenarios
• Writing Good User Stories
• Introduction to User Stories