Inhaltsverzeichnis
Du willst wissen:
Was ist User Story Writing ?
Wie funktioniert es?
Und vor allem:
Wie kannst du dieses „User Story Writing“ erlernen, um bessere Produkte zu erstellenund deine Karriere zu beflügeln?
Dann bist du hier so richtig wie die Klinke an der Türe.
In diesem Artikel erfährst du:
- Was User Story Writing ist – und was nicht.
- Die magische 4-Schritte-Formel, die beim User Story Writing immer funktioniert.
- 7 User Story Writing Techniken, die du heute umsetzen kannst, um morgen bessere Produkte zu erschaffen.
- 3 User Story Writing Bücher, die du auf jeden Fall lesen solltest.
Bist du bereit?
Dann gehts los.
11 Nuggets für
noch mehr Agilität
Mehr Agilität, bietet dieses E-Book für dich und dein Team.
Du wirst damit Teil der exklusiven E-Mail Liste und erhältst Gratis dieses E-Book.
Abmeldung jederzeit möglich.
Was ist User Story Writing?
„User Story Writing“ ist das entwickeln von Produkteigenschaften mit geschriebenen Wörtern.
Das ist die Beschreibung von Anforderungen, mit Wörtern und aus Sicht, des Benutzers (User).
Die dadurch entstehenden User Storys, werden gerne in der agilen Produktentwicklung benutzt.
Das User Story Writing funktioniert bestens in einem User Story Workshop nach dem User Story Mapping.
Eine User Story beschreibt mit Worten des Users, was er vom Produkt erwartet.
Damit User Storys besser verarbeitet werden können, werden sie überwiegend nach einer Vorlage erstellt.
Eine Vorlage für eine typische User Story sieht zum Beispiel so aus:
Als [Rolle] möchte ich eine [Funktion] für diesen [Nutzen]„.
Fortgeschrittene verwenden auch gern die „Wer, Was, Warum“ Vorlage.
Zum Beispiel: „Als Online-Shopper möchte ich die Möglichkeit haben, Artikelbewertungen zu lesen, um fundierte Kaufentscheidungen treffen zu können.„
User Storys helfen den Entwicklern, die Bedürfnisse der User besser zu verstehen und sich auf die Erstellung der Funktionen zu konzentrieren, die den größten Nutzen bringen.
Auch wenn von „User Story Writing“ gesprochen wird, ist eine User Story zunächst nicht viel mehr, als ein Versprechen über diese User Story zu diskutieren.
Jetzt wissen wir, was User Story Writing ist.
Gehen wir zum nächsten Schritt.
Was ist das Ziel von User Story Writing?
Mit User Story Writing soll eine klare und einfache Beschreibung der Anforderungen aus der Sicht des Users erfasst werden
Außerdem werden durch das User Story Writing weitere nützliche Ziele angestrebt:
- Benutzer in den Fokus stellen: User Storys helfen, die Anforderungen aus der Sicht des Users zu formulieren. Der Fokus der Beteiligten wird auf die Bedürfnisse und Erfahrungen des Benutzers gelenkt. Technische Aspekte treten in den Hintergrund.
- Gemeinsames Verständnis erlangen: Das Versprechen zur Diskussion, fördert die Kommunikation zwischen den Beteiligten. Missverständnisse werden reduziert und die Beteiligung an der Diskussion erzeugt Erinnerungen über Perspektive des Benutzers.
- Funktionen priorisieren: User Storys verdeutlichen ihren Wert und Nutzen durch ihre Eigenschaften und können dadurch leichter Priorisiert werden.
- Planung und Schätzung: Mit User Storys lassen sich komplexe Sachverhalte leichter verstehen und die Arbeit zur Umsetzung besser einschätzen und planen.
- Kreativität: Durch die Diskussion über User Storys entstehen positive Effekte die Innovation und Kreativität fördern und zulassen. Uer Storys sind lebendig und können bei neuen Erkenntnissen sogar noch während der Umsetzung angepasst werden.
Und damit haben wir auch das Ziel von User Story Writing definiert:
Nicht Formalismus.
Nicht Spezifikation.
Sondern einzig und allein nur eins:
Nützliche Produkte.
Wenn du jetzt denkst:
„Oh ja, ich möchte auch nützliche Produkte entwickeln. Doch wie funktioniert dieses User Story Writing?“
Dann kommt hier die Antwort:
Der universelle 4-Schritte-Formel im User Story Writing
Darf ich vorstellen:
Die Formel die dir hilft, User Storys richtig zu erstellen: RAMP
Sie steht für:
R = Rolle
A = Ausfertigen
M = Modifizieren
P = Priorisieren
Fakt ist:
Mit der RAMP-Formel bei deinem User Story Writing schreibst du einfach bessere User Storys.
Diese Formel ist recht neu in der agilen Welt – und trotzdem funktioniert sie bestens, weil sie auf erprobten Methoden beruht.
Und wie funktioniert diese RAMP-Formel?
So:
- Identifizieren, wer die Nutzer des Produktmerkmals sind (Rolle)
- Formulieren, welche Funktion die Rolle wünscht (Ausarbeiten)
- Bearbeiten bis alle Beteiligten die User Story verstehen (Modifizieren)
- Bewerten von Nützlichkeit und Geschäftswert (Priorisieren)
So die Theorie.
Wie diese Formel in der Praxis aussieht, zeige ich dir jetzt.
Fangen wir mit der Rolle an:
Schritt #1: Rollen identifizieren
Identifiziere und beschreibe typische Benutzer des Produkts. Diese können auf tatsächlichen Benutzerdaten basieren (Umfrage) oder hypothetisch sein.
Schritt #2: Ausarbeiten
Beschreibe die benötigte Produkteigenschaft in der User Story, aus Sicht der identifizierte Rolle oder Persona. Formuliere zur Qualitätskontrolle ein oder mehrere Akzeptanzkriterien und sorge dafür, das erste Ideen für Tests festgehalten werden.
Schritt #3: Modifizieren
Versammle dich nach den Entwürfen der User Storys mit allen Beteiligten, erkläre den Inhalt und überarbeite die User Story so lange, bis der Inhalt von allen verstanden wird und das widerspiegelt was der Nutzer will.
Schritt #4: Priorisieren
Lege gemeinsam mit den Stakeholdern einen Geschäftswert für die User Story fest und welche Dringlichkeit (Priorität) sie hat.
3 User Story Writing Bücher die du lesen solltest
Ein Klassiker von Mike Cohn.
Sein Buch beschreibt das Konzept der Benutzergeschichten als effektives Mittel zur Anforderungserfassung.
Es zeigt, wie User Storys in der Softwareentwicklung eingesetzt werden können.
Es behandelt erfolgreiche und erfolglose Implementierungen des Konzepts und bietet Übungen zur Verdeutlichung der wichtigsten Punkte.
Nach dem Lesen des Buches wirst du in der Lage sein, User Storys in deinem Unternehmen einzuführen und die Anforderungen für Softwareanwendungen präzise zu bestimmen.
Hier geht es zu seinem Buch:
User Stories Applied: For Agile Software Development (Addison Wesley Signature Series)
Vom Erfinder des User Story Mappings, Jeff Patton.
Das Buch erklärt die Verwendung von User Story Mapping als wertvolles Werkzeug in der Produktentwicklung.
Es betont die Bedeutung, sich auf die Benutzer und deren Bedürfnisse zu konzentrieren und nicht in der Begeisterung für Produktfunktionen zu verlieren.
Jeff Patton zeigt, wie Story Maps dabei helfen können, bessere Gespräche über das Projekt zu führen und ein gemeinsames Verständnis darüber zu entwickeln, was gebaut werden soll und warum.
Das Buch behandelt die Funktionsweise von Storys in agilen und lean Projekten und beschreibt den Lebenszyklus einer Story, angefangen von den Möglichkeiten bis zur Umwandlung in funktionierende Software.
Es bietet auch praktische Tipps zur Vorbereitung und Erstellung von Storys.
Hier geht es zu seinem Buch:
User Story Mapping: Discover the Whole Story, Build the Right Product.
Das Buch behandelt die Kombination von Scrum und User Stories als unschlagbares Duo in der agilen Softwareentwicklung.
Es erklärt die Grundlagen beider Konzepte und zeigt, wie User Stories in die Elemente und Abläufe von Scrum integriert werden können.
Von der Erstellung und Priorisierung des Product Backlogs bis zur Sprint- und Releaseplanung auf Basis von User Stories werden alle wichtigen Aspekte für den erfolgreichen Einsatz erläutert.
Ein Kapitel widmet sich dem Thema „Mobiles Arbeiten“ und beschäftigt sich mit den Anforderungen und Möglichkeiten agilen Arbeitens in mobilen Kontexten.
Es bietet Erfahrungen, Tipps und Ideen für das Führen von mobilen Scrum-Teams.
Hier geht es zum Buch:
7 User Story Writing Techniken, die du HEUTE umsetzen um MORGEN bessere Produkte zu erschaffen
tbd.
User Story Writing Technik #1: INVESTieren
„INVEST“ ist ein Akronym, das in der agilen Softwareentwicklung verwendet wird, um die idealen Merkmale einer guten User Story zu beschreiben.
Es steht für:
- I – Independent: Eine gute User Story sollte unabhängig sein, das heißt, sie sollte unabhängig von anderen Stories implementiert werden können. Dies erleichtert die Planung, da die Stories in beliebiger Reihenfolge umgesetzt werden können. Es vermindert auch die Abhängigkeiten zwischen den Teams und macht die Arbeit effizienter.
- N – Negotiable: User Stories sollten verhandelbar sein, sowohl in Bezug auf ihre genauen Anforderungen als auch auf ihre Implementierung. Sie sind kein festgeschriebener Vertrag, sondern vielmehr eine Einladung zur Zusammenarbeit und Diskussion zwischen den Entwicklern und den Stakeholdern. Dies ermöglicht eine größere Flexibilität und Anpassungsfähigkeit an sich ändernde Anforderungen.
- V – Valuable: Jede User Story sollte einen erkennbaren Wert für den Kunden oder Benutzer bieten. Dies hilft sicherzustellen, dass die Arbeit, die in die Umsetzung der Story investiert wird, zu einem greifbaren Nutzen führt und nicht nur technische Schulden oder unnötige Funktionen hinzufügt.
- E – Estimable: Eine gute User Story sollte in der Lage sein, geschätzt zu werden. Entwickler sollten in der Lage sein, eine angemessene Schätzung der Zeit und Ressourcen abzugeben, die zur Umsetzung der Story benötigt werden. Dies ist wichtig für die Planung und Priorisierung der Arbeit.
- S – Small: User Stories sollten klein genug sein, um in einem überschaubaren Zeitrahmen (z.B. in einem Sprint) umgesetzt zu werden. Dies erleichtert die Planung, erlaubt schnellere Feedback-Zyklen und hilft dabei, das Risiko von Verspätungen und Komplikationen zu minimieren.
- T – Testable: Jede User Story sollte testbar sein, das heißt, es sollte möglich sein, klare Kriterien zu definieren, anhand derer überprüft werden kann, ob die Story erfolgreich umgesetzt wurde. Dies stellt sicher, dass die implementierte Funktion den Anforderungen entspricht und korrekt funktioniert.
Jeder dieser Punkte trägt dazu bei, die Qualität und Effektivität der User Stories zu verbessern und so einen reibungslosen und effizienten Entwicklungsprozess zu unterstützen.
User Story Writing Technik #2: SMART sein
„SMART“ ist ein Akronym, das häufig zur Definition von Zielen verwendet wird.
Es steht für:
- S – Spezifisch (Specific): Ziele sollten klar und präzise definiert sein. Anstatt vage oder allgemeine Ziele zu setzen, sollte man genau festlegen, was erreicht werden soll. Das macht es einfacher zu verstehen, was genau erwartet wird und was man tun muss, um das Ziel zu erreichen.
- M – Messbar (Measurable): Ziele sollten messbar sein. Das bedeutet, dass es irgendeine Art von Metrik oder Messung gibt, mit der man feststellen kann, ob das Ziel erreicht wurde oder nicht. Durch messbare Ziele kann der Fortschritt überwacht und bei Bedarf angepasst werden.
- A – Erreichbar (Achievable): Ziele sollten erreichbar und realistisch sein. Ein Ziel, das jenseits der Fähigkeiten oder Ressourcen liegt, kann demotivierend wirken und ist letztlich nicht hilfreich. Erreichbare Ziele hingegen motivieren und führen zu konkreten Ergebnissen.
- R – Relevant (Relevant): Ziele sollten relevant sein. Sie sollten einen klaren Bezug zu den übergeordneten Zielen und Prioritäten haben. Irrelevante Ziele können Ressourcen verschwenden und von wichtigeren Aufgaben ablenken.
- T – Zeitgebunden (Time-bound): Ziele sollten einen klar definierten Zeitrahmen haben. Eine Deadline erhöht das Verantwortungsbewusstsein und hilft, Prioritäten zu setzen und den Fortschritt zu messen.
Das SMART-Prinzip ist ein effektives Werkzeug zur Zielsetzung, da es dazu beiträgt, klare, fokussierte und realistische Ziele zu definieren. Es kann in vielen verschiedenen Kontexten verwendet werden, einschließlich persönlicher Zielsetzung, Projektmanagement, Mitarbeiterbewertung und mehr.
User Story Writing Technik #3: Generalisierung vermeiden
Vermeide Generalisierungen in User Stories, weil sie Unklarheiten schaffen können.
Klare und spezifische User Stories helfen dir und deinem Team, die Anforderungen und Erwartungen zu verstehen.
Mit Generalisierungen besteht das Risiko, dass du und dein Team verschiedene Interpretationen dessen haben, was erwartet wird.
Das kann zu Fehlinterpretationen führen und dazu, dass du Funktionen entwickelst, die nicht den tatsächlichen Anforderungen des Kunden entsprechen.
Außerdem sind spezifische User Stories einfacher zu messen und zu testen. Wenn du genau weißt, was das Ziel ist, kannst du leichter feststellen, ob du es erreicht hast.
Mit anderen Worten:
Je spezifischer deine User Stories sind, desto besser kannst du sie umsetzen. Es hilft dir, den Aufwand besser abzuschätzen und sicherzustellen, dass das Endprodukt den Anforderungen des Kunden entspricht.
Hier sind einige Wörter, die oft in generalisierenden Aussagen verwendet werden:
- Alle
- Niemand
- Jeder
- Immer
- Nie
- Oft
- Selten
- Meistens
- Generell
- Typischerweise
- Üblicherweise
- Normalerweise
- In der Regel
- Relevant
Diese Wörter und Phrasen führen dazu, dass Aussagen ungenau und unspezifisch werden, da sie breite Kategorien oder Verhaltensweisen ohne Ausnahme darstellen.
Im Kontext von User Stories und Anforderungsdefinition ist es besser, spezifische, messbare und detaillierte Beschreibungen zu verwenden.
User Story Writing Technik #4: Geschlossene User Storys schreiben
User Stories müssen geschlossen formuliert werden, um Klarheit und Präzision zu gewährleisten.
Wenn du eine User Story schreibst, legst du eine bestimmte Anforderung oder Funktion fest, die entwickelt werden soll.
Eine geschlossene Formulierung hilft dir dabei, genau zu definieren, was diese Anforderung ist und wie das Endergebnis aussehen sollte.
Das reduziert das Risiko von Missverständnissen oder falschen Interpretationen.
Eine geschlossene Formulierung hilft dabei, die Grenzen der User Story festzulegen.
Sie macht deutlich, was in den Rahmen der User Story fällt und was nicht.
Das hilft dir und deinem Team, den Umfang der Arbeit zu kontrollieren und Feature Creep – das ständige Hinzufügen neuer Funktionen oder Anforderungen – zu vermeiden.
Eine geschlossene Formulierung sorgt für klarere Kommunikation mit allen Beteiligten.
Jeder kann die User Story lesen und verstehen, was erwartet wird, ohne zusätzliche Erklärungen oder Diskussionen.
Das spart Zeit und verhindert Kommunikationsfehler.
User Story Writing Technik #5: Nur 1 Akzeptanzkriterium
In einer User Story nur ein Akzeptanzkriterium zu haben, kann Vorteile haben.
Ein einzelnes, klar definiertes Akzeptanzkriterium hilft dir, den Fokus auf eine spezifische Funktion oder ein spezifisches Feature zu legen.
Es ermöglicht dir, die Geschichte und ihre Anforderungen sauber und klar zu halten.
Wenn du mehrere Akzeptanzkriterien in einer einzigen User Story hast, kann dies zu mehr Komplexität führen.
Es könnte schwieriger sein, die Story innerhalb eines Sprints zu vervollständigen.
Zudem könnte es schwieriger werden, die Story zu testen und sicherzustellen, dass alle Kriterien erfüllt sind.
Ein einzelnes Akzeptanzkriterium hilft auch dabei, die Unabhängigkeit der User Story zu bewahren.
Das bedeutet, dass die Story für sich alleine stehen kann und nicht von anderen Stories abhängt.
Dies erleichtert die Planung und Priorisierung.
Schließlich wird ein einzelnes Akzeptanzkriterium dazu beitragen, dass du und dein Team den Wert, den die User Story liefert, klarer erkennst.
Indem du dich auf ein einzelnes Kriterium konzentrierst, stellst du sicher, dass dieser Wert klar und deutlich ist.
User Story Writing Technik #6: Deseqenzieren
User Stories sollten keine Sequenz bilden und nicht voneinander abhängig sein, um Flexibilität und Effizienz in deinem Entwicklungsprozess zu gewährleisten.
Wenn User Stories voneinander abhängig sind oder eine Sequenz bilden, wird dies das priorisieren und organisieren einschränken.
Du wirst gezwungen, Storys in einer bestimmten Reihenfolge abzuarbeiten, auch wenn andere Stories dringender oder wichtiger sind.
Abhängigkeiten zwischen Storys können auch das Risiko von Verzögerungen und Komplikationen erhöhen.
Wenn eine Story verzögert wird, verzögern sich alle anderen Stories, die von ihr abhängen, ebenfalls.
Das kann dazu führen, dass dein gesamter Entwicklungsprozess ins Stocken gerät.
Unabhängige User Storys ermöglichen es dir und deinem Team, flexibler und reaktionsfähiger zu sein.
Du kannst die Arbeit besser auf dein Team verteilen und schneller auf Änderungen oder unerwartete Probleme reagieren.
User Story Writing Technik #7: Diskussion fördern
Es ist wichtig, den Diskurs über User Stories mit allen Beteiligten zu führen, um sicherzustellen, dass jeder die gleiche Vision und das gleiche Verständnis der Anforderungen hat.
Wenn du mit allen Beteiligten – einschließlich Entwicklern, Projektmanagern, Stakeholdern und Benutzern – kommunizierst, kannst du Missverständnisse und Fehlinterpretationen vermeiden.
Jeder hat die Möglichkeit, seine Perspektive einzubringen und Fragen zu stellen, was zu einem vollständigeren und genaueren Verständnis der User Story führt.
Ein offener Diskurs hilft auch dabei, sicherzustellen, dass die User Story wirklich wertvoll und relevant für den Endbenutzer ist.
Stakeholder und Benutzer können Feedback geben und sicherstellen, dass die geplante Funktion ihren Bedürfnissen und Erwartungen entspricht.
Die Kommunikation über User Stories die Zusammenarbeit und das Engagement des Teams wird gefördert.
Jeder fühlt sich in den Prozess einbezogen und verantwortlich für den Erfolg der User Story.
Dies wird die Motivation und Produktivität des Teams steigern und zu besseren Ergebnissen führen.
