Agile Teams erstellen User Stories, um Kundenbedürfnisse, wie Anforderungen für Software oder andere Leistungen, projektbezogen inhaltlich steuern und realisieren zu können. Neben einem grundsätzlich einfachen Aufbau, welcher definiert, was genau und warum möchte der Kunde eine bestimmte Geschäftslösung haben, haben User Stories den großen Vorteil, dass sie sich überaus detailliert erweitern oder mit anderen Methoden der Zielkundenbetrachtung kombinieren lassen.

Im (Online-)Marketing nimmt der Kunde längst eine ganz zentrale Position ein. Wer den Personenkreis, an den sich die eigenen Waren oder Dienstleistungen primär richten, in Blog-Beiträgen, Produktbeschreibungen, Werbetexten etc. optimal bedient, steigert seine Erfolgschancen in aller Regel enorm. Personas und Customer Journey Mapping haben heute feste Plätze auf der Marketing-Agenda zahlreicher Unternehmen, die Kundenwünsche bzw. Nutzerbedürfnisse wirklich verstehen möchten. Der Ansatz der User Stories ist jedoch nach wie vor für Viele Neuland.

FullImage

Was sind User Stories?

Laut Definition sind User Stories als Teil des Agile Works konkrete Anwenderszenarien, die in Alltagssprache formuliert werden und insbesondere Erkenntnisse zu spezifischen Anforderung (für Software, Webdesign, Marketing usw.) liefern.

Grundsätzlich werden User Stories (Nutzergeschichten) aus der Sicht wahrscheinlicher Nutzer oder Kunden geschrieben und erfassen das "Wer möchte was, warum?" hinsichtlich einer bestimmten Anwendung bzw. eines Sachverhalts, Prozesses etc. Anhand solcher Geschichten können agile Teams Kundenwünsche und nicht zuletzt Kundenprobleme auf einfache Weise sehr klar bestimmen.

Das Prinzip stammt aus der agilen Softwareentwicklung, findet aber längst auch in anderen Bereichen agiler Teamarbeit Anwendung. Die User Story wird gemäß ihrem agilen Hintergrund mitunter auch als Agile Story bezeichnet.

Die User Story ist nicht zu verwechseln mit einem Use Case. Letzterer stellt zwar ebenfalls Anforderungen in natürlicher Sprache und im Kontext spezifischer Nutzer dar, hier werden allerdings Erfolgs- und Misserfolgsszenarien eines formulierten fachlichen Problems dargestellt. Somit beinhaltet der Ansatz des Use Case mehrere Szenarien. Die User Story beschränkt sich hingegen auf ein konkretes Szenario.

Wie erstellt/schreibt man User Stories?

Bei der Generierung von User Stories gilt es - trotz der grundsätzlichen Einfachheit des Ansatzes - einige Dinge zu beachten. Zunächst sollten derartige Geschichten stets an einer bestimmten Umsetzungsschablone ausgerichtet werden, damit sie wirklich effektiv sind. Zudem sollten Sie als Anwender den Aufwand einschätzen können und wissen, was es mit User Story Splitting, dem INVEST-Prinzip sowie Abhängigkeiten zwischen User Stories auf sich hat.

Eine User Story sollte immer in möglichst kurzen Sätzen und mit einfachen Worten geschrieben werden. Damit lässt sich sicherstellen, dass alle beteiligten Kollegen sie gegebenenfalls auch ohne Expertenwissen verstehen.
Die Formulierung erfolgt stets aus der Sicht des Kunden oder Anwenders. Es gilt einen wirklichen Nutzen zu benennen.

Die Story sollte dabei insbesondere herausstellen, wer was warum möchte. Die Eckpfeiler der Fragestellung „wer“, „was“ und „warum“ sind hier entsprechend des jeweiligen Kontexts relativ frei mit einem konkreten Nutzer oder einer Rolle (wer), einem Sachverhalt oder einer Funktion (was) und einem Grund oder Wert (warum) zu belegen. Daraus ergibt sich beim Schreiben einer User Story die folgende grundlegende Satzstruktur: Als (Nutzer) möchte ich (Funktion), um (Wert) zu erreichen.

In diesem Zusammenhang wichtige Begriffe sind Epic Agile und Story Mapping Agile.

In agilen Epics werden User Stories gesammelt. Diese Sammlungen beschreiben Anforderungen in höheren Abstraktionsebenen. Die User Stories bilden hier die einzelnen Schritte, welche Nutzer oder Kunden durchlaufen, bis sie ein Epic abschließen.

Um ein agiles Userstory Mapping zu schaffen, werden grobe Prozess- und Arbeitsschritte einzeln in Epics festgehalten und in einem visuellen User Story Template dargestellt. Über ein derart visualisiertes User Story Mapping lassen sich die spezifischen Anforderungen sehr übersichtlich abarbeiten.
Die Planung von Tasks im Hinblick auf das Erreichen des jeweiligen Ziels kann somit besser eingeschätzt und zu jedem Zeitpunkt der Entwicklung anhand der Map präzise abgeglichen werden. Abweichungen sind schnellstens aufzudecken und es kann prompt zielsicher reagiert werden.

Eine wichtige Frage bei der Erstellung von User Stories ist: Wie schätzt man den entsprechenden Aufwand korrekt ein? Die kurze Antwort lautet: in Personentagen oder mit Story-Points.

Bei Story-Points geht es nicht in erster Linie um den Zeitaufwand einer User Story, sondern um die Erfassung deren struktureller Eigenschaften. Anhand dieser kann dann wiederum der Aufwand bestimmt werden. Dafür legt das Team zunächst ein Kriterium oder eine Verknüpfung von diversen Kriterien fest. Ein typisches Kriterium ist die Komplexität.

Bei der Nutzung von Personentagen werden alle notwendigen Arbeiten identifiziert und summiert. Oftmals dient hier eine User Story mit mittlerer Größe als Referenz. Die Schätzung erfolgt dann im Vergleich zu dieser Referenz.

Wenn User Stories zu umfangreich sind, müssen sie gesplittet werden, um sie innerhalb eines Sprints realisieren zu können. 
 
Wie gesplittet wird, sollte sich streng an dem Wert des Nutzers („Als [Nutzer] möchte ich [Funktion], um [Wert] zu erreichen.“) orientieren und nicht an der Technik.

Der Prozess erfolgt optimalerweise im Team. Das ermöglicht es, unnötige Abhängigkeiten zwischen User Stories, eine frühzeitige Beschreibung von Lösungen und die übermäßige Produktion von weniger lösungsorientierten Spike-Stories zu vermeiden.

Akzeptanzkriterien helfen dabei, herauszufinden, ob User Stories erfolgreich implementiert wurden. Hier werden stichpunktartig Ergebnisse festgelegt, die durch die User Story zu erfüllen sind.

Eine vielgenutzte Möglichkeit, um Akzeptanzkriterien zu definieren, ist das Hinterfragen von Schlüsselwörtern. Letztere sind insbesondere spezifische Verben, Adjektive und Substantive: 

  • Wer tut was, wann und wo?
  • Was geschieht als Konsequenz aus diesem Vorgang?
  • Welche Optionen hat der Akteur?

Unter der Verwendung derartiger W-Fragen sind Akzeptanzkriterien relativ einfach aufzustellen.
 

Das INVEST-Prinzip unterstützt agile Teams dabei, zu definieren, ob eine qualitativ gute User Story erstellt wurde?

Qualität zu bestimmen bzw. in gewissem Maß zu gewährleisten, ist wichtig, um maximalen Nutzen aus einer User Story generieren zu können.

Aufgrund der zweifelsohne großen Relevanz dieses Sachverhalts widmen wir INVEST unten noch genauere Aufmerksamkeit.

User Stories sollten stets unabhängig voneinander sein. Das gelingt in der Praxis jedoch nicht immer so einfach, wie es zunächst scheint. Regelmäßig stellen sich technische, inhaltliche bzw. fachliche, zeitliche oder normative bzw. regulatorische Abhängigkeiten heraus. Schon unterschiedliche Kompetenzen im Team können indirekt zu Abhängigkeiten bei der Realisierung von User Stories führen.

Um solche und ähnliche Abhängigkeiten effektiv auszuschließen, hilft es, eine Visualisierung im Sinne des Userstory Mappings durchzuführen. Im Zuge dessen sollten sich entsprechend kritische Punkte schnell ausmachen lassen. Eine alternative Methode ist es, Abhängigkeiten in separaten Tabellen oder als ergänzende Notizen zu dokumentieren.
 

Was macht eine gute User Story aus?

Um eine hohe Qualität und damit schließlich maximalen Nutzen für eine User Story sicherzustellen, wird in aller Regel auf das oben bereits kurz angesprochene INVEST-Prinzip zurückgegriffen. Dieses setzt die folgenden sechs Qualitätskriterien voraus.

  • I (Independent): Die User Story sollte nicht von einer anderen User Story abhängig sein.
  • N (Negotiable): Die User Story bildet eine Gesprächsbasis und kann gemeinsam weiterentwickelt werden.
  • V (Valuable): Die User Story manifestiert einen echten Vorteil für den Nutzer, Kunden oder auch Auftraggeber.
  • E (Estimatable): Die User Story kann über ausreichend konkrete Details von einem erfahrenen Team in ihrem Umfang geschätzt werden.
  • S (Small): Die User Story ist nicht zu umfangreich und beschränkt sich auf das Wesentliche im jeweiligen Kontext.
  • T (Testable): Die User Story kann über ihren Informationsgehalt getestet werden.
FullImage (copy 1)

Darüber hinaus sollten für qualitativ hochwertige User Stories folgende Faktoren berücksichtigt werden:

  • Der Fokus sollte immer besonders auf den Nutzer gerichtet sein.
  • Das Erstellen guter User Stories ist Teamarbeit – hier spielt Kommunikation, sprich die Bewertung von Anforderungen, Feedback etc., eine wichtige Rolle.
  • Durch die Aufstellung von Akzeptanzkriterien wird die Arbeit effizienter und das Ergebnis hochwertiger.
  • Weniger ist oft mehr – eine User Story sollte kurz und präzise formuliert werden.
  • User Stories sollten für jeden Beteiligten verständlich und gut sichtbar sein.
  • User Stories sollten einfach formuliert werden, so das Jeder im Team es sofort und eindeutig verstehen kann
  • User Stories allein sind nicht immer ausreichend – sie müssen für maximale Erfolge häufig gemeinsam mit Personas und Customer Journey Mapping verwendet werden.
  • Durch gezielte Workshops und Übungen können die Kompetenzen in puncto User Stories sehr effektiv optimiert werden – die Qualität der Stories steigt.

Zur Bewertung einer guten User Story, sollten folgende Fragen und Zusammenhang beantwortet werden:

  • Welches Problem adressiert die User Story?
  • Für wessen Problem bietet die Story eine Lösung?
  • Ist das Problem verstanden worden und wurde es ausreichend hinterfragt?
  • Ist das Problem lediglich eine Abbildung der Anforderung des Kunden? Gibt es, falls dies zutrifft, eine andere Lösungen für das Problem?
FullImage

SCRUM Userstory

Wie gestalten sich die Anforderungen in der Teamarbeit mit SCRUM?

User Stories bilden für SCRUM-Teams einen wichtigen Standard in der Formulierung von Anforderungen. Weiterhin sind sie zentraler Faktor in der Pflege des Backlogs, also der Liste aller Anforderungen für ein zu erreichendes Ziel.

Einerseits bleiben User Stories, wie wir oben ausgeführt haben, stets ein Format, um Anforderungen zu beschreiben. Andererseits nehmen sie im Rahmen der Backlog-Organisation aber auch die Rolle eines speziellen Hierarchietyps ein. Diese Stories sind dann innerhalb eines Sprints zu realisieren und bringen dem User oder Kunden einen konkreten Nutzen.

Außerdem können User Stories als Format verwendet werden, um SCRUM Epics oder Features zu beschreiben.

FAZIT

User Stories bieten einen einfachen, aber höchst wirkungsvollen Ansatz, um Kundenwünsche bzw. Nutzerbedürfnisse oder auch Kundenprobleme in einer universell verständlichen Sprache zu diskutieren, zu validieren und schließlich unter einem gemeinsamen Verständnis der entsprechenden Lösungen präzise zu bearbeiten.

Zielgruppen lassen sich mithilfe dieses Formats in ihren Bedarfen noch einmal differenzierter betrachten und verstehen. Als Ergänzung zu bzw. in Kombination mit Personas und Customer Journey Map können sie zeigen, wie die für diese Modelle festgelegten Eigenschaften, sprich insbesondere Herausforderungen und Wünsche der Personas sowie Touchpoints der Customer Journey, in der Praxis wirklich zusammenspielen (sollten). Anhand dieser Betrachtungen lassen sich dann zielgenau die perfekten Maßnahmen herausstellen.

Container mit Bild

Unsere Unterstützung rund um das Thema Customer Journey:

  • Gemeinsam mit Ihnen erstellen wir relevante Wunschkundenprofile und leiten daraus eine professionelle Customer Journey ab.
     
  • Wir legen relevante Kanäle fest und konzipieren eine individuelle Customer Journey Map speziell für Ihr Unternehmen.
     
  • Auf Basis dessen skizzieren wir eine positive User Experience entlang aller relevanten Touchpoints und setzen diese programmatisch um.
     
  • Zusätzlich unterstützen wir Sie gerne bei der strategischen Ausrichtung des Lead-Nurturings auf die definierte Customer Journey und erarbeiten konkrete Contentbausteine für die jeweiligen Phasen des Kaufprozesses.

Für ganzheitliches und erfolgreiches Online Marketing kümmern wir uns auch gerne um folgende Themen:

Haben Sie weitere Fragen?

Oliver Parrizas steht Ihnen für Ihre Fragen zum Thema gerne zur Verfügung.

icon phone+49-800-911-91-91 

icon kalenderWunschtermin buchen

Praxisorientiertes Wissen für die Realisierung Ihrer digitalen B2B-Projekte:

Der eigene Onlineshop

Erfahren Sie, welche E-Commerce-Trends nicht zu vernachlässigen sind und welche Features ein professioneller Onlineshop mitbringen sollte.

Marketing Automation

Erhalten Sie Einblick, wie Sie mit Marketing Automation Ihre Vertriebsressourcen effizienter einsetzen und neue Leads generieren können.

Content Marketing

Erhalten Sie exklusive Empfehlungen zur Konzeption bis hin zur idealen Umsetzung einer zielführenden Content Marketing Strategie.

B2B Website Relaunch

Informieren Sie sich über die stukturierte und zeitgemäße Realisierung eines B2B-Website Relaunchs.