Zeige mehr…

User Stories

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:

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:

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:

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.

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:

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

Weiterführende Informationen

Agile-Dienstleistungsportfolio von //SEIBERT/MEDIA
Agile Softwareentwicklungs-Projekte mit //SEIBERT/MEDIA

Oder stellen Sie eine unverbindliche Anfrage

Zeige mehr…
Zeige mehr…