User Story

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

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 Programming, das Kent Beck ab 1996 bei einem Projekt 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 Zeit 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 Projektplanung 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 Priorisierung 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.

Relevante Beiträge im Projekt Magazin
Methode: Story Mapping
von Torben Blankertz
Bewertungen
0
0 Kommentare
Bei der Entwicklung von Project hin zur heutigen Client Server-Lösung verfolgte Microsoft stets das Ziel, eine branchenunabhängige Projektmanagement-Software für sequentielle Planung zu entwickeln. In vielen Projekten gehören mittlerweile jedoch auch iterativ inkrementelle Vorgehensmodelle, wie z.B. Scrum zum Standard. Ein weiterer logischer Entwicklungsschritt war es daher, in den Project Client auch Funktionen für die agile Planung zu integrieren. Torben Blankertz stellt das neue agile Feature vor.
von Bettina Zastrow
8 Bewertungen
4.375
3 Kommentare
Mit der in Teil 1 erstellten Systemdefinition sind die Merkmale der neuen Software festgelegt. Um konkrete Anforderungen für die Entwickler abzuleiten, muss diese allerdings noch verfeinert werden. Im nächsten Schritt geht es deshalb darum, sogenannte Use Cases zu modellieren, die den Funktionsumfang der Software genauer beschreiben. Wie Ihnen das auch als Nicht-ITler gelingt, zeigen Bettina Zastrow und Elisabeth Wagner in diesem zweiten Teil der dreiteiligen Artikelfolge.
von Steffen Thols
3 Bewertungen
3.666665
0 Kommentare
Mit dem Burn-up-Chart hat Ihnen Steffen Thols im ersten Artikelteil eine alternative Darstellungsform für agile Projektplanung präsentiert. Im zweiten und abschließenden Artikelteil gibt er Ihnen eine Excel-Vorlage an die Hand, mit deren Hilfe Sie selbst ein Burn-up-Chart erstellen können. Die Schritt-für-Schritt-Anleitung anhand eines fiktiven Beispiels ermöglicht es Ihnen, sein Vorgehen nachzuvollziehen. Sie haben auch die Möglichkeit, die Vorlage für Ihre Bedürfnisse anzupassen.
von Steffen Thols
9 Bewertungen
3.555555
6 Kommentare
In Scrum als dem bekanntesten Vertreter von agilem Vorgehen wird die Projektplanung in einem Burn-down-Chart visualisiert. Im ersten Teil der Artikelserie stellt Ihnen Steffen Thols nach einer Gegenüberstellung klassischer und agiler Projektplanung eine alternative Darstellungsform agiler Projektplanung – den Burn-up-Chart – vor. Und er erklärt, in welchem Kontext sich dieser besser einsetzen lässt.
von Steffen Thols
13 Bewertungen
4.153845
3 Kommentare
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. Auch müssen entsprechende Rahmenbedingungen im Unternehmen geschaffen werden. Steffen Thols schildert, welche formalen und strukturellen "Stolpersteine" es bei der Konzeption von User Stories gibt und wie Sie diese umgehen können.
von Dr. Dirk Basten
14 Bewertungen
4.142855
5 Kommentare
Wie werden Aufwände für Software-Entwicklungen in der Praxis geschätzt? Wie zuverlässig sind diese Schätzungen? Wie könnten sie genauer werden? Eine Befragung von erfahrenen Projektmanagern zum Thema Aufwandsschätzung lieferte erstaunliche Resultate: Unter anderem waren die Befragten mit den Schätzwerten zufrieden, obwohl die tatsächlichen Kosten beträchtlich davon abwichen. Dr. Dirk Basten stellt die Ergebnisse dieser Studie vor und analysiert, warum Schätzungen die Ist-Werte nur selten richtig prognostizieren. Er leitet daraus konkrete Handlungsempfehlungen ab, wie sich die Genauigkeit von Aufwandsschätzungen erheblich steigern lässt.
von Dr. Oliver Linssen
8 Bewertungen
4
1 Kommentar
In agilen Software-Projekten, speziell in Scrum, hat sich zur Aufwandsschätzung in den vergangenen Jahren die Methode des Planning Pokers etabliert. Bei regelmäßiger Anwendung innerhalb eines Teams ermöglicht dieses Verfahren gute Prognosen. Dr. Oliver Linssen stellt in diesem Beitrag die Techniken vor, die für die Durchführung des Planning Pokers in Scrum erforderlich sind und gibt Empfehlungen, worauf Sie beim Einsatz in der Praxis achten sollten.
von Dominik Maximini
3 Bewertungen
3.333335
0 Kommentare
Im ersten Teil stellte Dominik Maximini ein Vorgehen vor, um Scrum-Projekte strukturiert zu planen und zeigte Fehler auf, die dabei häufig in der Praxis gemacht werden. In diesem zweiten und abschließenden Teil stellt er die einzelnen Planungsschritte an einem Praxisbeispiel im Detail vor.
von Dominik Maximini
3 Bewertungen
5
0 Kommentare
Genau wie in traditionellen Projekten nimmt auch in Scrum die Planung eine zentrale Rolle ein. Allerdings wird dort auf eine längere vorgelagerte Planungsphase verzichtet, stattdessen findet die Planung größenteils parallel zur Entwicklung statt. Dominik Maximini stellt im ersten Teil des Beitrags das Vorgehen bei der Planung kurz vor, beleuchtet Besonderheiten und zeigt Fehler auf, die in der Praxis häufig gemacht werden. Der zweite und abschließende Teil beschreibt das Vorgehen ausführlich an einem praxisnahen Beispiel.
von Dr. Arne Roock
8 Bewertungen
4.375
2 Kommentare
Scrum und Kanban kommen in der Softwareentwicklung immer häufiger zum Einsatz und haben in der Familie der Agilen Methoden inzwischen ihren festen Platz eingenommen. Doch sind diese beiden Ansätze überhaupt miteinander vereinbar? Und wenn ja, wie kann dies in der Praxis aussehen? Dr. Arne Roock erklärt in diesem Beitrag die Gemeinsamkeiten und Unterschiede der beiden Methoden und zeigt vier verschiedene Kombinationsmöglichkeiten auf. Projektleiter und Manager erhalten so eine Orientierung, welcher Weg für sie geeignet sein könnte. Und Teams, die bereits Scrum einsetzen, erhalten Anregungen, wie sie sich durch Kanban weiter verbessern können.
von Ralf Wirdemann
5 Bewertungen
3.8
3 Kommentare
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 spezifiziert werden sollen. Ein etablierter Weg dafür ist die Verwendung von User Stories. Ralf Wirdemann erklärt, wie User Stories funktionieren und wie sich die Anforderungen eines Scrum-Projekts mit Hilfe von User Stories beschreiben und verwalten lassen.
von Ralf Wirdemann
37 Bewertungen
4.324325
3 Kommentare
Viele Software-Produkte entsprechen nach Fertigstellung nicht den Vorstellungen des Kunden. Wo das traditionelle Projektmanagement allzu oft versagt, soll die agile Projektmanagement-Methode "Scrum" Abhilfe schaffen – mit kurzen Entwicklungszyklen und viel Kunden-Feedback. Ralf Wirdemann stellt Scrum vor.
von Klaus Marquardt
Bewertungen
0
0 Kommentare
Warum ist Software zu teuer, kommt zu spät, tut nicht genug oder ist einfach schlecht? Extreme Programming (XP) zeigt Wege, ein Projekt auch unter klassisch schwierigen Bedingungen auf Qualität und Effizienz zu optimieren. Diese ausführliche Einführung umfasst drei Teile. Im ersten Teil standen die Grundlagen und die Motivation von Extreme Programming sowie die wichtigsten Prinzipien im Vordergrund. Der zweite Teil stellte nach einem Blick auf Entstehungsgeschichte die Einsatzgebiete und Ziele vor. Abschließend werden die Verfahren, die XP zur Projektplanung einsetzt, erläutert. Die Verfahren zur "Extremen" Softwareentwicklung sowie die bisherigen Erfahrungen mit XP schließen in diesem dritten Teil die Einführung ab.
von Klaus Marquardt
1 Bewertung
5
0 Kommentare
Warum ist Software zu teuer, kommt zu spät, tut nicht genug oder ist einfach schlecht? Extreme Programming (XP) zeigt Wege, ein Projekt auch unter klassisch schwierigen Bedingungen auf Qualität und Effizienz zu optimieren. Diese ausführliche Einführung umfasst drei Teile. Im ersten Teil standen die Grundlagen und die Motivation von Extreme Programming sowie die wichtigsten Prinzipien im Vordergrund. Dieser zweite Teil stellt nach einem Blick auf Entstehungsgeschichte die Einsatzgebiete und Ziele vor. Abschließend werden die Verfahren, die XP zur Projektplanung einsetzt, erläutert. Die Verfahren zur "Extremen" Softwareentwicklung sowie die bisherigen Erfahrungen mit XP schließen im dritten Teil diese Einführung ab.
Alle relevanten Beiträge anzeigen
Tech Link