Was ist eine User Story?
Laut einem der Gründer der Agile-Bewegung, Alistair Cockburn, ist eine Story-Karte „ein Versprechen für ein Gespräch.“ Insbesondere ist sie ein Versprechen für ein Gespräch mit Ihrem Kunden, das zu einer Beschreibung einer Softwarefunktion aus dessen Perspektive führt. Dies ist die Grundlage einer User-Story – ein wesentlicher Bestandteil des Agile- und Lean-Softwareentwicklungslebenszyklus. Themen, Initiativen, Epics und Storys sind alles Bestandteile, ob groß oder klein, die dazu beitragen, die notwendigen Funktionen zu organisieren, um eine benutzerorientierte Softwarelösung zu erschaffen. Die Begriffe wecken Erinnerungen an die Welt der Literatur, und das hat seinen Grund. Eine User Story ist ein einfaches Narrativ, während verwandte Storys ein Epic bilden. Hier erklären wir, wie diese Begriffe zusammenhängen:
Thema: ein ehrgeiziges Ziel oder ein übergeordnetes Ziel
Initiative: eine Sammlung von Epics, die dazu beitragen, das Hauptziel zu erreichen
Epics: ein übergeordneter Geschäftsbedarf oder eine große User Story Diese lassen sich nur schwer einer einzigen Iteration implementieren, sodass sie in kleinere Storys unterteilt werden. In der Regel ist ein komplettes Epic in einer einzigen Version enthalten.
User Storys: kurze Anforderungen oder Benutzerszenarien, die einen gewissen Mehrwert bieten und aus der Perspektive des Benutzers geschrieben werden. Jede Story ist auf einen Sprint oder eine Iteration begrenzt.
Beispiel:
Das Thema (ganz links) ist das übergeordnete Geschäftsziel, das aus zugehörigen Initiativen besteht, aus Epics, die diese Initiativen unterstützen, und aus Storys (ganz rechts), die detaillierte Anforderungen beschreiben.
Eine Softwareentwicklungsorganisation kann das hehre Ziel haben, ihre Lösung zu modernisieren. Um diese Aufgabe zu erfüllen, muss das Unternehmen eine unvergessliche Benutzererfahrung bieten. Zum Beispiel muss im Rahmen dieser Benutzererfahrung eine moderne Web-Oberfläche bereitgestellt, eine reaktionsschnelle Performance geboten und die Kompatibilität mit eine Vielzahl von Benutzer-Geräten sichergestellt werden. In diesem Szenario wird jedes dieser Epics in konkrete User Storys unterteilt.
Was ist eine Epic User Story?
Ein Epic ist ein übergeordneter Geschäftsbedarf oder eine große User Story. Epics sind zu komplex, um sich einem einzigen Sprint oder einer einzigen Iteration implementieren zu lassen, sodass sie in mehrere kleinere User Storys unterteilt werden. Der Vorteil von Epics besteht in der Möglichkeit, größere Ideen zu entwickeln und im Rahmen dieser zusammenzuarbeiten, bevor zahlreiche User Storys erstellt werden. Das Epic kann als Originalidee beibehalten werden, was einen zukünftigen Referenzpunkt schafft.
Was ist der Zweck einer User Story?
Eine User Story dient als Hilfe bei der Entwicklung einer Softwarelösung. Leider ist es nicht ungewöhnlich, dass Softwarelösungen entwickelt werden, die bei der vorgesehenen Kundenbasis einfach keinen Anklang findet. User Storys sollen dieses Risiko mindern, indem sie ein klares und gründliches Verständnis der Anforderungen der Endbenutzer liefern, wodurch sichergestellt wird, dass die Softwarefunktionen die Erwartungen erfüllen.
Wie verwenden Unternehmen User Storys?
User Storys sind eines der Hauptwerkzeuge, die in der Agile-Entwicklung verwendet werden. Sie werden erstellt, um funktionale und nicht funktionale Funktionen und Anforderungen zu beschreiben, und bilden eine priorisierte Liste der Funktionen, die für die Entwicklung vorgesehen sind. Diese Liste wird als Produkt-Backlog bezeichnet.
User Storys werden Teil einer User-Story-Map, einer Methode, die verwendet wird, um User Storys entlang einer horizontalen und vertikalen Achse anzuordnen und so verschiedene Benutzerfreundlichkeitsstufen darzustellen. Die horizontale Achse führt durch die Aktivitäten, die erklären, wie der Benutzer mit dem System interagiert, um eine Funktion zu nutzen. Die vertikale Achse stellt zunehmende Komplexitätsstufen dar. Die erste Zeile ist eine grundlegende Darstellung der Funktion. In der nächsten Zeile werden ein wenig mehr Funktionalitäten hinzugefügt und so weiter. Jeder User Story wird ein Story-Point oder eine theoretische Schätzung des Aufwands oder des Schweregrads im Hinblick auf die Entwicklung der Funktionalität zugewiesen. Viele Unternehmen verwenden automatisierte Story-Mapping-Tools. Die beliebtesten Tools sind Jira, Rally von CA, StoriesOnBoard und FeatureMap.
Vorlage für eine Story-Map
Sie können diese Vorlage auch verwenden, um Ihre eigene Story-Map zu erstellen. Sie können die Vorlage mithilfe von Microsoft Word ausfüllen oder sie mithilfe von Post-its an einer Wand nachbilden. Passen Sie die Anzahl der Felder basierend auf den Entwicklungsanforderungen Ihres Unternehmens an.
Was sind die Merkmale einer User Story?
Unabhängig vom verwendeten Agile-Framework, wie Extreme Programming (XP), Kanban, DAD (Disciplined Agile Delivery), AMDD oder Scrum, sind User Storys immer gleich. Die User Story beschreibt die Art des Benutzers: die Persona, die von ihm gewünschte Funktion und den Nutzen, den der Benutzer von der Funktion erwartet. Eine starke User Story wird unter Berücksichtigung der Role-Feature-Reason-Struktur (RGB) geschrieben:
Als
Die User Story sollte die folgenden Qualitäten aufweisen:
Vollständig genug sein, um den Mehrwert für den Benutzer aufzuzeigen
Benutzerorientiert sein
Mit einem Epic beginnen
Kurz, einfach und klar sein
Bei Bedarf unterstützende Dateien und Dokumentationen enthalten
Umfassend genug sein, um einen Mehrwert zu demonstrieren, aber einfach genug, um in einer einzigen Iteration entwickelt werden zu können
Auf der Grundlage des Inputs aller Beteiligten geschrieben sein
Flexibel und verhandelbar sein, ohne sich auf andere Storys oder Funktionen auszuwirken
Einfach zu testen sein
Akzeptanzkriterien (Zufriedenheitsbedingungen) für Tester umfassen
Manchmal werden die Begriffe User Storys und Systemanforderungen synonym verwendet. Traditionell verwendet die Waterfall-Entwicklung Systemanforderungen, um zu definieren, wie eine Softwarelösung funktionieren sollte. Dabei geht man umfassend ins Detail und nennt Risiken, Umfang und andere entwicklungsspezifische Richtlinien. User Storys hingegen sind einfach, fördern Diskussionen und unterstützen die Agile-Entwicklungsmethode, die für Zusammenarbeit und Veränderung steht.
Wie bereits erwähnt, sollten User Storys einfach und dennoch vollständig sein. Eine gute User Story lautet zum Beispiel wie folgt:
Als Bankkunde möchte ich in der Lage sein, einen Scheck online einzulösen, damit ich nicht zur Bank gehen muss.
Hier ist ein Beispiel für eine User Story, die zu detailliert ist:
Als Bankkunde möchte ich in der Lage sein, einen Scheck online einzulösen sowie historische Kontoauszüge anzuzeigen und auszudrucken, damit ich nicht zur Bank gehen muss.
Was ist ein Story-Point?
Jeder User Story wird ein Story-Point zugewiesen, eine Messung des Aufwands oder des Schwierigkeitsgrads im Hinblick auf die Entwicklung und Implementierung. Teams können einziffrige Zahlen (1, 2, 3), mehrziffrige Zahlen (100, 200, 300) oder ein anderes Zahlenformat verwenden. Das Verhältnis ist das Wichtige. Zum Beispiel erfordert eine Story, der 200 Story-Points zugewiesen wird, doppelt so viel Aufwand wie eine, der 100 Story-Points zugewiesen sind.
Was sind Benutzerakzeptanzkriterien?
Akzeptanzkriterien, die auch als Zufriedenheitsbedingungen bekannt sind, stellen sicher, dass die Softwarelösung die Anforderungen der Endbenutzer oder Beteiligten erfüllt. Diese Kriterien können Leistungsanforderungen, Standards, Szenarien und Regeln des Systemverhaltens umfassen. Das Testteam verwendet Akzeptanzkriterien, um zu überprüfen, ob die Entwicklung abgeschlossen ist. Sobald diese Parameter erfüllt sind, wird die Story oder Funktion als „erledigt“ angesehen.
So schreiben Sie eine effektive User Story
Das Schreiben Ihrer ersten User Storys kann schwierig sein, insbesondere, da sie die Grundlage für die Funktionalität Ihres Produkts sind. User Storys werden am häufigsten in der Anfangsphase der Entwicklung entwickelt und bei der Planung von Iterationen und Sprints verwendet, aber sie können jederzeit erstellt werden (zu Beginn, um den Umfang des gesamten Projekts/der Lösung zu skizzieren; während der Entwicklung, um neue Storys zu identifizieren, unnötige Storys zu entfernen und Storys in kleinere Teile zu unterteilen) und für die nächste Iteration zum Backlog hinzugefügt werden.
Die folgenden 10 Tipps helfen Ihnen, effektive User Storys zu erstellen:
Benutzer stehen an erster Stelle: Der Zweck einer User Story besteht darin, die Funktionalität aus der Perspektive eines Benutzers darzustellen. Achten Sie darauf, Benutzer zu befragen und benutzerspezifische, sachliche Informationen aufzunehmen. In einigen Fällen ist der Benutzer möglicherweise nicht eine Person, sondern ein System.
Personas definieren: Ihre Benutzer zu verstehen, ist ein wesentliches Element beim Schreiben einer User Story. Erschaffen Sie fiktive Charaktere, die Ihre Ziel-Endbenutzer darstellen (dies können Verbraucher, Käufer, häufige Käufer, Buchhalter oder Personaler sein). Kaufverhalten, Probleme, die die Benutzer lösen möchten, und allgemeine Ziele sind alles wichtige Informationen über Ihren idealen Kunden. Verwenden Sie diese Persona-Namen und nicht die generische Benutzerrolle, wenn Sie Ihre Storys schreiben.
Zusammenarbeiten: Stellen Sie sicher, dass alle relevanten Beteiligten während der Erstellung von User Storys in einem Raum zusammenarbeiten können. Produktmanagement, Ingenieure/Entwickler, Tester, Kundensupport, Vertrieb und Kunden sollten alle vertreten sein.
Einfachheit beibehalten: Halten Sie die Story einfach und klar. Formulieren Sie im Aktiv und konzentrieren Sie sich nur auf wichtige Fakten.
Beginnen Sie mit Epics und gehen Sie dann ins Detail: Beginnen Sie mit einer größeren User Story, anhand derer sich die Gesamtfunktion vollständig erfassen lässt, und schlüsseln Sie dann die Details der eigentlichen Funktion auf. Jeder Schritt eines größeren Prozesses sollte einer einzelnen Story entsprechen. Mit diesem Prozess können Sie die Story in einen einzigen Sprint oder eine Iteration einfügen.
Fügen Sie Akzeptanzkriterien hinzu: Schreiben Sie Akzeptanzkriterien, die festlegen, was im Rahmen dieser bestimmte Story als „erledigt“ gilt. Die Akzeptanzkriterien sind ein perfekter Beitrag zu Testfällen, die das Testteam verwendet, um sicherzustellen, dass die Funktion für den Benutzer bereit ist.
Beginnen Sie mit Post-its oder Karteikarten: Als User Storys im Rahmen von Extreme Programming (XP) erstmals aufkamen, wurden sie auf einfachen Karteikarten erfasst. Die Verwendung dieser Methode fördert die Zusammenarbeit und Diskussion, die Sichtbarkeit und die Transparenz und ist eine einfache Möglichkeit, Dinge in einer kollaborativen Umgebung zu bewegen und Storyboards zu gestalten.
Präsentieren Sie User Storys in einem zugänglichen Bereich: Wenn Sie User Storys in einem offenen Bereich sichtbar machen, wie an einer Wand oder auf einem Whiteboard, fördert das die Zusammenarbeit während des gesamten Entwicklungsprojekts. Die Darstellung der Story kann mit Diagrammen, Mock-ups, Arbeitsablaufdiagrammen, Story-Maps und Skizzen verbessert werden.
Feedback annehmen: Agile Entwicklung steht für Flexibilität. Feedback ermöglicht es Ihnen, die Funktionalität zu verfeinern, um sicherzustellen, dass das Produkt einen Mehrwert für den Benutzer liefert.
Fügen Sie Zeitschätzungen hinzu: Die Zeit, die für die Fertigstellung einer User Story benötigt wird, ist für die Planung von Iterationen und Releases wichtig. Zeitschätzungen können helfen, Aufgaben und Teilaufgaben den Teammitgliedern zuzuweisen.
Es gibt zwei Haupttechniken, die Ihnen helfen können, User Storys zu schreiben:
Die drei Cs: Die im Jahr 2001 von Ron Jeffries entwickelte Drei-Cs-Formel umfasst eine Karte oder ein Post-it, ein Gespräch zwischen den Benutzern, Entwicklern, Testern und Produktverantwortlichen über die Funktion und die Bestätigung, dass das Ziel erreicht wurde.
INVEST: Diese Kriterien, die im Jahr 2003 von Bill Wake eingeführt und durch Mark Cohns Buch User Stories: für die agile Software-Entwicklung mit Scrum, XP u.a. populär gemacht wurden, bewerten den Wert einer User Story, indem sichergestellt wird, dass sie unabhängig ist (kann in jeder Reihenfolge entwickelt werden), verhandelbar, wertvoll (für einen Benutzer oder ein Unternehmen),schätzbar (im Hinblick auf den Abschluss)kurz (Entwurf, Test und Programmierung in einer einzigen Iteration) und testbar.
Um mehr über das Schreiben einer User Story zu erfahren und Tipps und Vorlagen zu erhalten, die Ihnen helfen, loszulegen, lesen Sie How to Write a User Story in Software Development that Actually Focuses on the User.
Wer schreibt User Storys?
Es geht nicht unbedingt darum, wer die User Story schreibt, sondern wer bei der Entwicklung der User Story beteiligt ist. Das Ziel ist eine gemeinschaftliche Diskussion, die zu einer User Story führt. Produktmanagement, Ingenieure/Entwicklung, Tester, Kundensupport, Vertrieb und vor allem Kunden sollten am Prozess teilnehmen. Der Produktmanager oder Produktverantwortliche ist in der Regel während des gesamten Entwicklungslebenszyklus für die User Storys zuständig.
Was ist die Definition von „Done“ in Agile?
Jedes Team verfügt über eine eigene Definition von erledigten oder abgeschlossenen Aufgaben in der Agile-Entwicklung, und diese Definition variiert je nachdem, was für die Fertigstellung bewertet wird – eine User Story, ein Sprint oder ein vollständiges Release. Es gibt Kriterien, die festgelegt werden können, damit sichergestellt wird, dass eine Funktion wirklich vollständig ist. Die Checkliste von Kriterien kann die folgenden Punkte enthalten:
Ist der Code geschrieben?
Wurde der Code getestet?
Erfüllt die Funktion die Akzeptanzkriterien?
Lässt sich die Funktion in die bestehende Lösung integrieren und ist sie mit ihr kompatibel?
Sind die Produktspezifikationen aktualisiert worden?
Wurde die Produktdokumentation aktualisiert?
Sind Anwendungsfälle und User Storys dasselbe?
Die Begriffe User Story und Anwendungsfall werden ähnlich verwendet, aber Anwendungsfälle enthalten viel detailliertere Details im Vergleich zu einer User Story. Eine User Story wird während einer gemeinschaftlichen Diskussion geschrieben; sie stellt die Perspektive eines Benutzers dar und umfasst das Ziel des Benutzers und die Akzeptanzkriterien des Benutzers.
Sind Anwendungsfälle und User Storys dasselbe?
Die Begriffe User Story und Anwendungsfall werden ähnlich verwendet, aber Anwendungsfälle enthalten viel detailliertere Details im Vergleich zu einer User Story. Eine User Story wird während einer gemeinschaftlichen Diskussion geschrieben; sie stellt die Perspektive eines Benutzers dar und umfasst das Ziel des Benutzers und die Akzeptanzkriterien des Benutzers.
Dieselben Informationen sind in einem Anwendungsfall enthalten, aber der Anwendungsfall geht noch tiefer und skizziert funktionale Anforderungen der Lösung, einschließlich aller Möglichkeiten der Benutzer-/Systeminteraktion und möglicher Risiken. Viele Entwicklungsprojekte integrieren User-Story-Erstellung, Story-Mapping und Anwendungsfälle, um ein vollständiges und gründlich durchdachtes Produkt zu erschaffen.
User-Story-Beispiele, -Vorteile und -Herausforderungen
User Storys werden in der Regel basierend auf funktionalen Attributen geschrieben. Zum Beispiel: „Als Kunde möchte ich einen Scheck elektronisch einlösen können, um nicht zur Bank oder zum Bankautomaten fahren zu müssen.“ Es gibt jedoch nicht funktionale Merkmale oder technische Einschränkungen, die auch wichtig sind. Bei diesem Bank-Beispiel können die technischeren Einschränkungen wie folgt einbezogen werden: „Als Kunde möchte ich 12 Schecks im Rahmen einer einzigen elektronischen Transaktion einlösen können.“ Das Verständnis der spezifischen Details (die technischer erscheinen können) ermöglicht es dem Entwicklungsteam, über die Einschränkungen nachzudenken, die sie möglicherweise in eine offene User Story einbeziehen müssen, um sie machbar zu machen.
Vorlagen für User Storys und andere Agile-Vorlagen sind hier zum Download verfügbar.
User-Story-Vorteile
User Storys sind ein häufiges Element der Agile-Entwicklung, und die Verwendung dieser bietet umfangreiche Vorteile für diejenigen, die die Lösung entwickeln, und für den Kunden, der die Software nutzt.
Customer Benefit
Find increased value in the software solution.
Build a positive, collaborative relationship with vendor.
Increase satisfaction.
Eliminate technical details in order to include customers and non-technical stakeholders.
Focus on customer needs.
Software Vendor Benefit
Increase competitive advantage.
Encourage collaboration and cooperation.
Boost transparency.
Reduce risk.
Increase customer satisfaction.
Focus on value.
Avoid unnecessary adjustments to the backlog.
Eliminate technical details that may hinder collaboration.
Develop creative solutions.
Support the flexibility of Agile development.
User-Story-Herausforderungen
Wie bei jedem Geschäftsprojekt gibt es auch bei User Storys Herausforderungen, die auftreten. In Mike Cohns Buch „User Stories: für die agile Software-Entwicklung mit Scrum, XP u.a.“ wird das Kernproblem in der Softwareentwicklung mit dieser einfachen Beobachtung identifiziert: „Softwareanforderungen sind ein Kommunikationsproblem.“ Im Rahmen des User-Story-Entwicklungsprozesses sollen diese Herausforderungen gemeistert werden, aber die vermehrte Kommunikation kann für einige interne Beteiligte mühsam erscheinen.
Zu den weiteren Herausforderungen gehören die folgenden:
Sicherstellen, dass die User Story umfassend genug ist, um einen Mehrwert zu demonstrieren, aber einfach genug, um in einer einzigen Iteration entwickelt werden zu können
Wenn Sie sich darauf konzentrieren, wie Sie technische Details erstellen und einbeziehen, die in dieser Phase der Entwicklung unnötig sind
Gespräche und Zusammenarbeit können zeitaufwändig und abschreckend wirken.
User Storys helfen, Softwareentwicklungsorganisationen von einem voreingenommenen, anforderungsgesteuerten Ansatz hin zu einer kollaborativen, benutzerorientierten Herangehensweise zu bewegen. User Storys sind einfach, unkompliziert und spiegeln die Erwartungen des Kunden wider. Diese Taktik fördert Gespräche zwischen internen Beteiligten und Kunden, was zu einem konkurrenzfähigeren Produkt führt, das für die wichtigsten Personen in Ihrem Geschäftsbereich, Ihre Benutzer, wertvoll ist.
Lernen Sie, wie Sie die Transparenz von User Storys mit Smartsheet für die Softwareentwicklung steigern
Befähigen Sie Ihr Team, über sich selbst hinauszuwachsen – mit einer flexiblen Plattform, die auf seine Bedürfnisse zugeschnitten ist und sich anpasst, wenn sich die Bedürfnisse ändern. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.