Projektmanagement-Methode
Alle Methoden
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.
Autor
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.
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.
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.
Ergebnis
- 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
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
Durchführung ...
Sie sind noch kein Abonnent?
1 Monat
kostenlos und unverbindlich testen
- Management Summaries und Zugriff auf über 1800 Fachartikel.
- Methoden, Tools und Vorlagen
- Riesiges Archiv und jede Woche neue Inhalte!
- Kostenlos und ohne Risiko einen Monat lang testen
Praxistipps ...
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/)
Ergänzende Methoden
Links
Fachartikel zur Methode
Bewertungen und Kommentare
(nur angemeldete Benutzer)
26.07.2017
Mehr zum Thema
Artikel
Notizen aus der Projektküche: Es muss nicht immer Kaviar sein!
Wer kochen kann, kann auch Projekte managen, behaupte ich immer.
Mit der Fahnenbildung konstruktiver entscheiden
Eine interessante Alternative zur Brainstorming-Methode ist die "Fahnenbildung". Sie können damit nicht nur Ideen entwickeln, sondern sorgen auch für Lösungen, in denen sich alle Teammitglieder gut wiederfinden. Die Excel-Vorlage dient zu...
Projektmanagement im Umbruch
Mehr zum Thema
PlanenLeistungsumfang