User stories sind einfach, aber äußerst leistungsfähige Konstrukte: Sie beschreiben einzelne Funktionen aus der Sicht des Anwenders, ausgedrückt in einer festen, kompakten Form. Sie spiegeln wider, was eine bestimmte Klasse von Benutzern benötigt und welchen Wert sie erzielt. Das format ist sehr einfach und leicht zu verwenden. Es gibt verschiedene Variationen, darunter:
Warum User Stories?
User Stories bieten eine hervorragende Möglichkeit, Ihr Produkt klar zu definieren., Eine Reihe genau definierter, priorisierter User Stories kann Ihnen dabei helfen, die Funktionalität Ihres Produkts in „einfachem Englisch“ zu artikulieren — ohne technische Details und Implementierungsdetails.
Der „User Story“ – Ansatz ermöglicht sinnvolle Produktdiskussionen sowohl innerhalb des Produktentwicklungsteams als auch mit externen Stakeholdern.
Richtig geschriebene User Stories bieten eine solide Basis für Kommunikation und Zusammenarbeit — und konzentrieren sich auf das, was für den Nutzer am wichtigsten ist., Im Vergleich zu anderen Mitteln zur Erfassung und Dokumentation von Benutzeranforderungen und Produktspezifikationen haben sie zumindest die folgenden Vorteile:
- User Stories helfen, teamübergreifende Klarheit darüber zu erreichen, was für wen, warum und wann erstellt werden soll. Da sie leicht zu definieren, zu verstehen und zu überarbeiten sind, können sie zur Standardmethode für die Kommunikation und Zusammenfassung der Funktionalität des Produkts sowohl durch technische als auch durch nichttechnische Mitglieder werden. Sie sind äußerst nützlich für Produkt-Scope-Diskussionen oder als Einstiegspunkte für technische Tieftauchgänge. Sie sind Schlüsselelemente des agilen Engineerings.,
- User Stories fördern die Teilnahme von nicht-technischen Mitgliedern. Moderne Softwareprojekte sind in der Regel komplex und beinhalten eine breite Palette von Technologien, Akronymen und Implementierungsoptionen. In vielen Fällen wird die Terminologie oder die Fachsprache — auch innerhalb eines einzigen Teams-nicht allgemein verstanden, was zu „Lärm“ und Risiken für das Projekt führt. User Stories entfernen diese technische Dimension, sodass jedes Mitglied des Teams einen Beitrag leisten kann, indem es einfach „als Benutzer“ denkt., Das Team kann nicht-technische Sprache verwenden und effektiv bei der Definition, Herausforderung oder Priorisierung von User Stories zusammenarbeiten. Die Auswirkungen auf die Zusammenarbeit und Teamdynamik können erheblich sein.
- Sie helfen bei der Definition des gesamten Produkts — als eine Reihe von soliden, klug priorisierten Geschichten. Das Produktentwicklungsteam kann groß denken, den übergeordneten Satz von User Stories definieren und dann Prioritäten zuweisen (die den erwarteten Wert für den Benutzer, die Komplexität, Abhängigkeiten und andere Geschäftsprioritäten widerspiegeln). Sie müssen keine harten Entscheidungen treffen und Elemente als „außerhalb des Geltungsbereichs“ kennzeichnen., Stattdessen können Sie diesen „verrückten“ Ideen eine niedrigere Priorität zuweisen, während Sie die User Stories nach oben verschieben, die die Kernfunktionalität Ihres Produkts widerspiegeln. Das Definieren der „Schnittlinien“, die den Umfang für jede Iteration, Phase oder Version bestimmen, hängt dann von den verfügbaren Ressourcen und der Geschwindigkeit des Teams ab.
Großartige Benutzergeschichten schreiben
Das Format ist unkompliziert und das Schreiben von Geschichten ist einfach. Aber große zu schreiben könnte ein bisschen schwierig sein. Hier sind einige Richtlinien zu beachten:
User stories ≠ Aufgaben
User stories sind keine Aufgaben., Tatsächlich benötigt eine einzelne Story möglicherweise Hunderte einzelner Aufgaben, um erfolgreich ausgeführt zu werden. Bei Aufgaben geht es um Implementierung; User Stories sind über Definition.
Konzentrieren Sie sich beim Kompilieren Ihrer Geschichten darauf, Klarheit über Ihre Produktfunktionen zu schaffen — das Was, nicht das Wie.
Bleib auf hohem Niveau
Du musst auf hohem Niveau sein, aber auch genau und auf den Punkt. Geschichten müssen einfach und solide sein. Dies hilft Teammitgliedern und Stakeholdern, die Bedürfnisse der Benutzer zu verstehen und Zeit mit der Klärung von Buzzwords, Terminologie und Akronymen zu vermeiden. Verwenden Sie einfach eine einfache und genaue Sprache.,
Verstehen Sie die Benutzer
Sie müssen die tatsächlichen Benutzer Ihres Produkts entdecken und studieren — erfassen Sie ihre Profile, Standpunkte, Erwartungen und die damit verbundenen Schmerzpunkte.“Benutzerforschung und andere Techniken können Erkenntnisse generieren, die Ihnen helfen, die Benutzer und ihre Bedürfnisse besser zu verstehen.
Unabhängig von den Techniken benötigen Sie die Anzahl der Schlüsselbenutzer-idealerweise in Form von Personas -, bevor Sie mit dem Kompilieren von Benutzergeschichten beginnen.,
Denke als Benutzer
<als eine Besondere Klasse von Benutzer – / persona /Rolle> Teil einer user story definiert den Blickwinkel, die Perspektive, wie der Nutzer wahrnimmt, die Funktionalität zusammengefasst in der Geschichte.
Dies ist von entscheidender Bedeutung — der Product Owner und das gesamte Team müssen aus der Sicht eines Benutzers denken und die zugrunde liegenden Bedürfnisse und den erwarteten Wert verstehen.,
Think big
Wenn Sie ein Produkt als Backlog von User Stories beschreiben, gibt es keinen guten Grund, Ihr Denken nach Budget, Zeit, Machbarkeit oder Kosten einzuschränken.
Eine gute Praxis ist es, groß zu denken und „verrückte“ User Stories in den Backlog zu lassen. Der administrative Aufwand für die Aufrechterhaltung eines erweiterten Produktrückstands ist gering; Der daraus resultierende Wert-in Bezug auf Produktklarheit, Vision und Chancen — ist enorm.,
Verwenden Sie Epics
Epics können die Form von übergeordneten Storys annehmen, die große Funktionen beschreiben-sie erfordern normalerweise eine erhebliche Menge an Arbeit über mehrere Sprints hinweg. Eine andere Art, Epen zu betrachten, sind Gruppierungen/ Container verwandter, kleinerer Geschichten, die alle einem gemeinsamen Ziel dienen. Epen sind gut für die Organisation Ihrer Geschichten und die Bereitstellung des großen Bildes.,
Verwerfen Sie nicht-priorisieren Sie stattdessen
Angesichts eines effektiven Priorisierungsprozesses ist es ratsam, Ihren Produktrückstand weiterhin mit neuen Benutzergeschichten zu bereichern und neue Benutzerinteraktionsszenarien, „zufällige Ideen“ oder die Ausgabe von Produktinnovationsaktivitäten zu beschreiben.
Um das potenzielle Rauschen zu verwalten, müssen Sie die neuen Einträge richtig gruppieren und priorisieren. In jedem Fall filtern/verwerfen Sie keine Elemente aus Ihrem Backlog: De-Scoped-Elemente werden normalerweise vergessen, während de-priorisierte Elemente auffindbar bleiben und unter den richtigen Bedingungen relevant werden können.,
Je nach Kontext kann die Priorisierung von User Stories ein kniffliger Prozess sein. Sie müssen den Wert jeder Geschichte, für den Benutzer und für das Unternehmen schätzen. Sie müssen die Komplexität messen, die Machbarkeit und die Kosten/den Aufwand schätzen, die zum Erstellen und Freigeben der Funktion erforderlich sind. Sie müssen Kreuzabhängigkeiten in Ihrem Backlog identifizieren und eine bestimmte Reihenfolge zwischen bestimmten Einträgen erzwingen.
Setup für den Erfolg – nicht nur Akzeptanz
Teams definieren häufig Benutzerakzeptanztests und zugehörige Akzeptanzkriterien. Akzeptanz ist jedoch nicht genug — Sie müssen sich auf Erfolg einstellen., Als Produktmanager benötigen Sie mehr als eine Bestätigung, dass „es so funktioniert, wie es sollte „oder“ gemäß den Spezifikationen.‘
Sie benötigen Metriken, die auch mit direktem Benutzerfeedback verknüpft sind und erfassen, wie glücklich und engagiert Ihre echten Benutzer sind. Während die Akzeptanz gut ist, um den Entwicklungslebenszyklus der Funktion zu steuern, geht es beim Erfolg um mittel-/langfristige Auswirkungen und Werte, die für echte Benutzer Ihres Produkts geschaffen werden. Sie müssen beides definieren — auf Produkt-und/oder Epic-und/oder Story-Ebene.
Tag-Geschichten, Metadaten hinzufügen
Komplexe Produkte erfordern Hunderte von user stories., Für eine einfachere Navigation und Verwaltung müssen Sie Ihre Storys effektiv benennen, kategorisieren und taggen. Nach den ersten Überarbeitungen einer Story sollten Sie vermeiden, die Beschreibung umzubenennen oder drastisch zu ändern, da dies zu Verwirrung und Lücken im Team führen kann.
Ordnungsgemäße Verwaltung der Metadaten Ihrer Storys-Status, Fortschritt, Links, Prioritäten, Ressourcen usw. – hilft, Ihren Backlog zu erkunden, zu überwachen und zu verstehen.
Halten Sie sich nicht an Haftnotizen!,
ja, eine Wand voller bunter Klebezettel sieht Phantasie und hilft Ihrem team angezeigt, beschäftigt und produktiv zu sein :), Aber Sie müssen eine ernsthafte und spezielle Werkzeuge, um Sie ordnungsgemäß zu verwalten, zu bereichern, zu priorisieren und Geschichten zu teilen.,
In besonderen Fällen, wie z.B. einer Brainstorming—oder Ideationssitzung, Es ist in Ordnung, den ersten Satz von User Stories mithilfe von Haftnotizen zu erfassen-vorausgesetzt, Sie dokumentieren dann alle in einem geeigneten Produktmanagementsystem. Wenn Sie dies nicht tun und Ihre Geschichten nur auf Haftnotizen halten, werden Sie wahrscheinlich Chancen in Bezug auf Klarheit, Innovation, Effizienz und Zusammenarbeit verpassen.,
Sie benötigen noch Spezifikationen
Es ist großartig, einen priorisierten Satz gut definierter User Stories zu haben, aber es ist nur der Anfang. Das Team muss die Geschichten — aus technischer Sicht-analysieren und die notwendigen technischen Artefakte erstellen.
Im Idealfall werden Geschichten einer spezifischen Dokumentation zugeordnet, die alle technischen Details enthält, die aus Sicht des Software-Engineerings erforderlich sind. Sie bieten die Einstiegspunkte für detaillierte technische Spezifikationsdokumente und andere detaillierte Artefakte.,
Visualisierung hilft
Eine Always-on (digital) Visualisierung der Top-Priority User Stories nach Kategorie, Thema oder Epic könnte für die Zusammenarbeit und Ausrichtung zwischen Teams und Stakeholdern äußerst nützlich sein. Neben Statistiken, Problemen, Blockern und Fortschrittsindikatoren kann eine Storymap über interaktive Bildschirme im Kollaborationsbereich bereitgestellt werden.
User Stories bieten eine großartige Möglichkeit, die Funktionalität eines Softwareprodukts oder Systems schnell und genau zu beschreiben., Sie sind auch sehr effektiv bei der Erfassung der Ergebnisse von Brainstorming-Sitzungen, Design-Sprints, Hackathons und anderen innovationsgeführten Prozessen, bei denen ein Strom von Ideen kompakt und strukturiert erfasst werden muss.