User Storys erstellen

English
Writing User Stories

User Storys sind kurze, einfach gehaltene Beschreibungen einer Funktionalität oder eines Gegenstands aus der Perspektive der Anwender oder Kunden. Die Beschreibung erfolgt zumeist in einem einfachen Schema:

Englisch: As a <type of user>, I want <some goal> so that <some reason>.

Deutsch: Als <Rolle der beschreibenden Person>, möchte ich <Funktion/Gegenstand>, damit ich <Nutzen>.

Beispiel: Als Anwender möchte ich, dass beim Anklicken der "Schnelldruck"-Schaltfläche die aktuelle Dokumentauswahl an den Standarddrucker gesendet wird, damit ich Zeit spare.

Im Gegensatz zum herkömmlichen Anforderungsmanagement werden User Storys lösungsoffen formuliert. Diese Form ermöglicht Raum für spätere Änderungen und erleichtert Detaillierungen, die mitunter zu Beginn eines Projekts nicht möglich sind. User Storys werden während der gesamten Laufzeit eines agilen Projektes erstellt und dienen primär als Input für das Product Backlog.

User Storys erstellen

User Storys erstellen

English
Writing User Stories

User Storys sind kurze, einfach gehaltene Beschreibungen einer Funktionalität oder eines Gegenstands aus der Perspektive der Anwender oder Kunden. Die Beschreibung erfolgt zumeist in einem einfachen Schema:

Englisch: As a <type of user>, I want <some goal> so that <some reason>.

Deutsch: Als <Rolle der beschreibenden Person>, möchte ich <Funktion/Gegenstand>, damit ich <Nutzen>.

Beispiel: Als Anwender möchte ich, dass beim Anklicken der "Schnelldruck"-Schaltfläche die aktuelle Dokumentauswahl an den Standarddrucker gesendet wird, damit ich Zeit spare.

Im Gegensatz zum herkömmlichen Anforderungsmanagement werden User Storys lösungsoffen formuliert. Diese Form ermöglicht Raum für spätere Änderungen und erleichtert Detaillierungen, die mitunter zu Beginn eines Projekts nicht möglich sind. User Storys werden während der gesamten Laufzeit eines agilen Projektes erstellt und dienen primär als Input für das Product Backlog.

User Storys erstellen

Einsatzmöglichkeiten

User Storys sind ein verbreitetes Konzept zur Beschreibung von Anforderungen in agilen Projekten. Sie dienen als Gesprächs- und Diskussionsgrundlage zur Vereinbarung des Leistungsumfangs und werden im Laufe des Projekts im Team weiterentwickelt.

Daniel Reinold und Christian Botta live erleben in der PM Welt @home!
PM Welt

Erleben Sie den Vortrag "5+ visuelle Quick-Hacks – Für eine bessere Kommunikation und Kooperation" sowie 30 weitere Speaker in der PM Welt @home.

Das Thema der Konferenz lautet
Stark durch Kooperation! Zusammen.Arbeiten.Grenzenlos.
Die Teilnehmer erhalten in den unterschiedlichen Vorträgen, Diskussionen und Workshops konkrete Praxistipps und Impulse für ihren Projektalltag

 

 

Ergebnisse
  • Ggf. Epics als übergeordnete, grobe User Storys
  • Vollständig beschriebene User Storys als Input für das Product Backlog
  • Konsolidierte Akzeptanzkriterien für die User Storys
  • Optional: weitere ergänzende Informationen für die weitere Arbeit mit den User Storys, z.B. Fact-Sheets zu bestehenden Software-Komponenten
Vorteile
User Storys fungieren als Kommunikationsmittel zwischen Product Owner und Development Team und ermöglichen es, die Anforderungen sowohl aus Business- als auch aus technischer Sicht zu verstehen.
User Storys reduzieren die Unsicherheit über die zu implementierende Funktionalität.
Übersetzungsfehler von natürlicher Sprache (des Kunden) in abstrakte Modelle (z.B. Use-Case-Diagramme) werden eliminiert.
Auf Grund Ihres hohen Abstraktionsniveaus verringern User Storys den Druck, unsichere Detailaussagen zu einem frühen Zeitpunkt treffen zu müssen.
Die Verwendung von User Storys entlastet die Formulierung der Anforderungen von technischen Detailfragen. Deren Lösung obliegt vollständig dem Entwicklerteam oder anderen involvierten Fachabteilungen.
Grenzen, Risiken, Nachteile
Wenn keine Abstimmung mit dem Development Team möglich ist, sollten User Storys nicht verwendet werden. In diesem Fall empfiehlt es sich, auf herkömmliche Techniken des Requirements Engineerings wie z.B. Use Cases auszuweichen.
User Storys sind kein Ersatz für detaillierte Spezifikationen!
Mangelnde Kommunikation bzw. Abstimmung hinsichtlich des Inhalts der User Story im Team kann zu unzureichenden Ergebnissen der Implementierung führen.
Voraussetzungen
  • Die Kunden oder Benutzer der Anforderung / Funktionalität müssen bekannt sein, da User Storys aus der Kundensicht erstellt werden.
  • Aktive Beteiligung der Kunden bzw. Benutzer an der Erstellung der User Storys
  • Das Team muss bereit sein, aktiv und engagiert die User Storys zu diskutieren.
  • Zeit und Wille, die User Storys fortlaufend einem kritischen Blick zu unterziehen
Qualifizierung
  • Die Beteiligten müssen mit der Methodik vertraut sein.
  • Methoden-Neulinge sollten sich den grundsätzlichen Aufbau von User Storys vor Beginn ansehen und das Ausfüllen mit fiktiven Beispielen trainieren.
  • Der Besuch eines Storytelling-Workshops bzw. die inhaltliche Auseinandersetzung mit dem Thema Storytelling ist empfehlenswert.
Benötigte Informationen
  • Erwartete Leistung einer Funktion / eines Produkts aus Kundensicht (anfordernde Rolle).
  • Akzeptanzkriterien, die zur Zielführung beitragen (werden im späteren Verlauf detailliert).
Benötigte Hilfsmittel

Ein digitales (z.B. Textverarbeitung, spezielle Software) oder analoges Tool (z.B. Moderationskarten) zur Erfassung der User Storys

Herkunft

Das Konzept der User Story wurde unter anderem von Dr. Ivar Jacobson (Erfinder der Use Cases) erstellt. Ivar Jacobsen erweiterte das System im späteren Verlauf unter dem Namen "Use Case 2.0" (Jacobson, Ivar; Spence Ian; Bittner, Kurt: USE-CASE 2.0. The Guide to Succeeding with Use Cases, 2011, https://www.ivarjacobson.com/publications/white-papers/use-case-ebook) als Ergänzung im Rahmen des Requirements Engineerings.

Auch Ron Jeffreys gilt als ein Erfinder der User Story, da er diese bereits 2001 in einem Blogbeitrag diskutiert (Jeffreys, Ron: Essential XP: Card, Conversation, Confirmation, 2001, http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/)

Durchführung: Schritt für Schritt

"A User Story is a brief statement of intent that describes something the system needs to do for the user." (Dean Leffingwell: A User Story Primer, 2009)

Die folgenden Schritte beschreiben die Erstellung einer User Story. Die Erstellung kann durch den Kunden, den Product Owner, ein Teammitglied oder einen anderen Stakeholder erfolgen. Grundsätzlich kann jede Rolle eine User Story erstellen.

Wenn eine Person außerhalb Ihres Teams (z.B. der Kunde) die User Storys anfertigt, achten Sie darauf, diese Person auch im weiteren Projektverlauf eng einzubeziehen. Dies ist notwendig, um adäquat auf Änderungen bei den entsprechenden User Storys reagieren zu können.

Um leichter in die Kundenrolle zu schlüpfen, sollten User Storys mit Hilfe von sog. "Personas", also fiktiven Charakteren der Zielgruppe erstellt werden (s. Schritt 2).

Schritt 1: Analyse und Recherche

Wenn Sie die User Storys erstmalig anfertigen, ist es sinnvoll, die betroffenen Rollen ausgiebig zu analysieren und rollenspezifische Daten zu erheben. Dies kann z.B. mittels Interviews oder durch eine Webrecherche erfolgen. Im Gespräch mit Stakeholdern sind folgende Informationen für die Ermittlung von Zielen relevant:

  • Arbeitsweise der Rolle (z.B. elektronisch, analog, eingesetzte Tools)
  • Haltung des Stakeholders gegenüber der geplanten Änderung (z.B. Initiator der Weiterentwicklung, Festhalten an bestehender Lösung usw.)
  • Unzufriedenheit mit bestehender Lösung (z.B. lange Reaktionszeit, keine Vorauswahl bei Eingaben usw.)
  • Wünsche und Anforderungen an neue Lösung (z.B. Möglichkeit der Spracheingabe, automatische Fehlererkennung usw.)

Im Rahmen einer Webrecherche tragen Sie bei Bedarf weitere Informationen, z.B. Studien, Marktanalysen oder Dokumentationen zu bestehenden Komponenten zusammen.

Schritt 2: Erstellen Sie Personas!

Die Anfertigung von Personas dient der Vertiefung des Kundenverständnisses. Erstellen Sie Personas, die von der Zielsetzung Ihres Projekts betroffen sind. Personas haben in der Regel einen Namen, ein Bild, Charaktereigenschaften, Verhaltensweisen und ein Ziel. Das Ziel ist der Vorteil, den die Person mit Hilfe des Produkts erzielen will oder das Problem, welches das Produkt lösen soll. Weitere Elemente der Beschreibung einer Persona können z.B. sein:

  • Beruf, z.B.: "Informatiker", "Abteilungsleiter"
  • Alter, z.B.: "40 Jahre", "Berufsanfänger", "kurz vor Renteneintritt"
  • Bildungsstand, z.B. "Studium", "kaufmännische Lehre"
  • Abteilung, z.B. "zentrale IT"
  • Business-Ziele, z.B. "Kostenreduktion"
  • Einstellung, z.B. "offen für neue Wege"
  • Mögliche Anwendungsfälle für die zu entwickelnde Lösung, z.B. "Fokus Automatisierung von Regeltätigkeiten"
  • Kontext der Benutzung, z.B. "im Rahmen des monatlichen Geschäftsberichts"
  • Aufgaben, die für den Abschluss relevanter Szenarien notwendig sind, z.B. "grafische Aufbereitung in Form von Entwicklungstrends"

Kürzen oder erweitern Sie diese Liste entsprechend Ihrer Anforderung bzw. Einschätzung.

Je nach Projektumfang wird eine hohe Anzahl an Personas notwendig sein. Rechnen Sie daher mit ca. 30 Minuten Aufwand für die Erstellung einer Persona.

Praxistipps ...

Varianten ...

Ergänzende Methoden

Planning Poker

Schätzen Sie spielend einfach die relativen Aufwände für die User Storys oder anderen Aufgaben zusammen mit dem Umsetzungsteam!

Team Estimation Game

Mittels kollektiver Betrachtung schätzen Sie mit hoher Genauigkeit und dank des kurzen und intuitiv verständlichen Regelwerks mit geringem Aufwand. Die Gestaltung als Spiel fördert die aktive Mitarbeit in der Gruppe.

Sprint Review

Halten Sie Ihr agiles Projekt auf Kurs und beschließen Sie notwendige Maßnahmen zur Steuerung, in dem Sie nach jedem Sprint das Feedback der Stakeholder zum Produktinkrement einholen!

Sprint Retrospektive

Reflektieren und analysieren Sie mit dem Scrum Team den zurückliegenden Sprint! Leiten Sie gemeinsam aus den positiven und negativen Erfahrungen Maßnahmen ab, um im nächsten Sprint die Produktivität des Entwicklungsteams zu erhöhen.

Sprint Planning

Planen Sie mit dem gesamten Scrum-Team den nächsten Sprint und sorgen Sie so für einen stabilen Entwicklungsprozess!

World Café

Lösen Sie die Probleme der Welt beim "Kaffeekränzchen"! World Café ist ein kreativer Ansatz zur Ideenfindung in Großgruppen: In entspannter Atmosphäre tauschen die Teilnehmer in wechselnden Untergruppen an Stehtischen ihr Wissen aus.

Kanban Light

Sorgen Sie für hohe Transparenz bei der Aufgabenplanung für das Projektteam und verkürzen Sie die Durchlaufzeit einzelner Aufgaben durch die Überwachung und Steuerung entsprechender Verantwortlichkeiten. Regeltermine fördern den teaminternen Austausch.

Fachartikel zur Methode

User Stories beschreiben Anforderungen an eine Software aus Sicht des Nutzers. Obwohl sie einen klaren, einfachen Aufbau haben, gilt es bei der Konzeption einiges zu beachten.

Das agile Vorgehensmodell Scrum erfreut sich in der Softwareentwicklung zunehmender Beliebtheit, da es ein einfaches und flexibles Vorgehen erlaubt. Allerdings gibt es in Scrum keine Vorgaben, wie Anforderungen von Anwendern erfasst und …

Unlocked Content
Teil 1:
Projektinitiierung und Planung
Für IT-Projekte bringt die Scrum-Methodik viele Vorteile, der Einsatz in SAP-Entwicklungsprojekten scheint daher naheliegend. Doch in der Praxis bestehen hier einige Herausforderungen. So birgt z.B.

Aufgabengebiete

Download PDFDownload PDF
Download PDF (English)Download PDF (English)

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
1 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 17
Kommentare 1

Alle Kommentare (1)

Stefan
Hinz

Guter Einstiegsartikel! Alle Grundlagen verständlich erklärt. Kleinigkeit: - Misverständnis möglich - Unter Punkt 5 wird der in SCRUM vorbelegte Begriff "Review" in anderem Kontext verwendet. Hier geht es um eine Überprüfung der User Stories auf Zielorientierung und nicht um das Iterative Meeting zur Präsentation von Entwicklungsartefakten. Vielleicht meinten die Autoren das "Refinement", in dem Product Owner und Team Stories besprechen und einschätzen.