User Story

Eine User Story ist eine aus Anwendersicht umgangssprachlich und umsetzungsneutral formulierte Anforderung an eine Software.

User Story

Eine User Story ist eine aus Anwendersicht umgangssprachlich und umsetzungsneutral formulierte Anforderung an eine Software.
Wir empfehlen zum Thema Agile
Zertifizierter Product Owner und Scrum Master

Lassen Sie sich in einem nur 3-tägigen, kombinierten Praxistraining zum Product Owner und zum Scrum Master zertifizieren.  Mehr Infos

Wesentliches Merkmal von User Storys ist, dass sie in natürlicher Sprache verfasst sind und eine Interaktion des Anwenders mit der Software beschreiben. Sie sind deshalb keine technische Spezifikation, sondern beschreiben eine Erwartungshaltung des Anwenders.

Story Cards werden zu User Storys

Als Ursprung des User-Story-Konzepts gilt Extreme ProgrammingExtreme ProgrammingExtreme Programming ist eine Arbeitsmethode zur kundenorientierten Entwicklung von Software, die sich auf den zu erstellenden Quellcode und den kürzesten Weg dorthin konzentriert. Typisch für Extreme Programming ist die enge Verflechtung von Entwicklung und Qualitätssicherung in sehr kurzen Zyklen (Programmierung in Paaren), das Arbeiten in kleinen, flexiblen Teams mit fest definierten Rollen und der beständige Kontakt zum Kunden, der beständig verfügbar sein muss., das Kent Beck ab 1996 bei einem ProjektProjektEin Projekt ist ein einmaliger Geschäftsprozess , der von der Geschäftsführung der Trägerorganisation anhand eines Business Cases genehmigt wird, von einer temporären Organisationseinheit gemanagt wird, ein spezifiziertes Werk erstellt und dieses zu einem definierten Termin und zu vorgegebenen Kosten zur Abnahme an einen Kunden liefert. für Chrysler erstmalig in Form von "Story Cards" einsetzte (Wikipedia: Extreme Programming, 2018). Im Rahmen dieses Projekts prägte Alistair Cockburn den Ausspruch: "A story card is a promise for conversation" (Cockburn, Alistair: Origin of story card is a promise for a conversation, 2017). Daraus entwickelte sich der "CCC"-Dreischritt für die Behandlung von User Storys: Card, Conversation, Confirmation (Jeffries, Ron: Essential XP: Card, Conversation, Confirmation, 2001).

Use Case und User Story

User Storys stellen eine intuitivere Formulierung von Use Cases dar. Ivar Jacobsen bezeichnet sie deshalb auch als "Use-Case Narratives" (Jacobsen, Ivar; Spence, Ian; Bittner, Kurt: Use Case 2.0. The Guide to Succeeding with Use Cases, 2011). Während Use Cases normalerweise streng formalisiert in UML notiert werden, so dass sie nur noch für Experten verständlich sind, können User Storys auch von Anwendern verstanden und z.T. sogar selbst formuliert werden.

Das Role-Feature-Reason- oder Connextra-Template

Aufgrund der weiten Verbreitung tragen viele Anwender zur Weiterentwicklung des User-Story-Konzepts bei. So gibt es insbesondere eine Reihe von Schemata, die das Formulieren von User Storys vereinheitlichen und erleichtern sollen. Das bekannteste und am weitesten verbreitete Schema ist das in den 1990er Jahren bei der britischen Software-Entwicklungsfirma Connextra entwickelte Role-Feature-Reason-Schema:

  • Als [Rolle / Persona]
  • möchte ich [Tätigkeit, Anforderung],
  • um [Zweck, Ziel]
Dieses Schema dient zur Unterstützung bei der Formulierung von User Storys, darf jedoch nicht als starres Formular angesehen werden. Gleiches gilt für alle anderen verwendeten Schemata.

Epics und User Storys

Die allgemeine Definition von User Storys erlaubt es, dass sowohl detaillierte (z.B. "Als Online-Besteller möchte ich den Warenkorb abspeichern, um später den Kauf fortzusetzen") als auch sehr allgemeine Anforderungen (z.B.: "Als Endkunde möchte ich meine Waren online kaufen, um ZeitZeitZeit ist eine der zentralen Steuerungsgrößen des Projektmanagements und bildet neben Kosten und Leistungsumfang im sog. Magischen Dreieck einen der drei Eckpunkte. Mittlerweile sind Qualität, Risiko und Nutzen als weitere Steuerungsgrößen etabliert. Je nach Projektart ist der Faktor Zeit besonders kritisch, z.B. im Veranstaltungsmanagement oder bei Wartungs- und Instandhaltungsprojekten. zu sparen") formuliert werden. Für übergreifende User Storys, die in weitere User Storys strukturiert werden, hat sich deshalb zur Unterscheidung die Bezeichnung "Epic" eingebürgert.

INVEST-Kriterien für User Storys

Als Qualitätskriterien für User Storysschlug Bill Wake sechs Aspekte vor, die er im Akronym "INVEST" zusammenfasste (Wake, Bill: INVEST in Good Stories, and SMART Tasks, 2003):

  • I: Independent
  • N: Negotiable
  • V: Valuable
  • E: Estimable
  • S: Small
  • T: Testable

Backlogs und Story Maps

Die Verwendung von User Storys für die ProjektplanungProjektplanungProjektplanung ist der Prozess, Ablauf, Umfang, Kosten, Ressourcen, Qualität und andere Aspekte eines Projekts zu planen. und -steuerung kann auf unterschiedliche Weise erfolgen. Sie können sowohl in traditionell als auch agil gemanagten Projekten als Basis für die Erstellung des Leistungsumfangs verwendet werden.

Die einfachste Vorgehensweise besteht darin, die User Storys unstrukturiert im Backlog zu sammeln, nach Priorität zu sortieren und beginnend mit der höchsten Priorität sequentiell abzuarbeiten.

Erweist sich eine einfache PriorisierungPriorisierungPriorisierung bedeutet die quantitative Bewertung von gleichartigen Elementen nach einem einheitlichen Maßstab und die anschließende Sortierung nach der so ermittelten Kennzahl in einer eindeutigen Reihenfolge. Zweck der Priorisierung ist es, die für ein bestimmtes Ziel wichtigsten Elemente (z.B. Aufgaben, Projekte, Produkte usw.) zu ermitteln und entsprechend zu berücksichtigen. als nicht mehr ausreichend, werden User Storys in sog. Story Maps strukturiert. Dort werden die Epics oben horizontal in der Reihenfolge ihres Auftretens angeordnet. Nach unten werden dann mit zunehmender Detailtiefe die zum jeweiligen Epic gehörenden User Storys eingetragen.

Bewertungen

Gesamt
Bewertungen 11
Kommentare 0