User Stories schreiben: Vorlage, Beispiele & Kriterien

Software-Updates sind der Schlüssel zur Steigerung des Mehrwerts für Kunden, denn sie ermöglichen die ständige Erweiterung des Funktionsumfangs Ihrer Produkte.

User Stories sind eine Beschreibung einer Softwarefunktion, die aus der Perspektive des Endnutzers geschrieben wird. Auf diese Weise können agile Teams besser einschätzen, welche Wünsche die Nutzer haben und die besten Funktionen bereitstellen.

Wir haben für Sie die wichtigsten Punkte zum Schreiben effektiver User Stories zusammengestellt. Im Folgenden erfahren Sie, wie Sie die Nutzererfahrung in den Mittelpunkt stellen und so den größtmöglichen Nutzen erzielen.

Wenn Sie mehr darüber erfahren möchten, wie Sie agile Teams ideal managen können, klicken Sie doch hier auf den Link:

Was ist eine User Story?

Eine User Story ist eine kurze, nichttechnische Beschreibung einer Softwarefunktion aus der Perspektive des Endnutzers. Sie folgt typischerweise dem Format: «Als [Rolle] möchte ich [Funktion], damit [Nutzen]». Durch diese Struktur versteht das Entwicklungsteam sofort, wer von der Funktion profitiert und warum.

Der Zweck der Erstellung von User Stories besteht darin, genau zu beschreiben, wie sich eine Softwarefunktion auf den Mehrwert für Kunden überträgt. Oder anders ausgedrückt: Welchen Nutzen hat diese Softwarefunktion für den Endnutzer?

Ein Endnutzer, auch als Kunde bezeichnet, muss nicht zwangsläufig ein externer Abnehmer sein. Ein Endnutzer kann auch ein interner Kunde oder ein Teammitglied sein, das von diesem Arbeitsergebnis profitiert. Die Definition des Endnutzers hängt letztlich vom Zweck der Softwarefunktion ab, die Sie entwickeln.

User Stories sind ein zentraler Bestandteil einer agilen Herangehensweise. Es gibt viele Möglichkeiten, sie zu erstellen, z. B. mit Haftnotizen oder Karteikarten. Die effektivste Art aber, User Stories zu erstellen und nachzuverfolgen, ist die Nutzung einer agilen Projektmanagement-Software.

Mithilfe einer solchen Software können Sie User Stories in Echtzeit anpassen, bearbeiten und weiterverfolgen. Bei der agilen Softwareentwicklung steht der Mensch im Mittelpunkt. User Stories helfen Ihnen dabei, den Fokus konsequent auf den Endnutzer zu legen.

Wer schreibt die User Stories?

In der Regel verfasst die produktverantwortliche Person, auch genannt der Product Owner, die User Stories auf Grundlage von Nutzerforschungsergebnissen und stellt sie in einer Liste für das Entwicklungsteam zusammen, die auch als Product Backlog bezeichnet wird. Obwohl theoretisch jeder User Stories schreiben kann, liegt es in der Verantwortung des Produktmanagers, alle Informationen bereitzustellen, die das Entwicklungsteam für die Durchführung seiner Initiativen benötigt.

Anschließend legt das Entwicklungsteam Prioritäten fest und entscheidet, welche User Stories im Sprint-Planungsmeeting berücksichtigt werden sollen.

Welche Rolle spielen User Stories in Scrum?

In einem Scrum Projekt spielen User Stories eine sehr wesentliche und zentrale Rolle. Sie sind Teil einer Epic und die Grundlage von Aufgaben für das Entwicklungsteam:

• Unter Epic versteht man eine sehr grobe und übergeordnete User Story. Diese ist allerdings zu groß, als dass sie in einem Sprint erledigt werden könnte. Sie wird deshalb in Stories aufgeteilt.

• Die Stories sind die eigentlichen User Stories. Diese enthalten die aufgeschriebenen Anforderungen, auf Basis dessen das Scrum-Team den Aufwand für die Realisierung einschätzt.

• Danach werden die Stories in einzelne Aufgaben aufgeteilt, welche in einer vereinbarten Zeitspanne erledigt werden sollen. Übersteigt eine Aufgabe eine solche Zeitspanne, wird sie wieder in weitere Unteraufgaben zerteilt.

Wer nutzt die User Stories?

User Stories werden im Rahmen von Scrum als auch Kanban angewendet.

• In Scrum helfen User Stories Ihrem Team, während der Sprintplanung ein besseres Verständnis zu erlangen.

• Bei Kanban nehmen die Teams User Stories in ihr Backlog auf und arbeiten während ihres Sprints daran. User Stories liefern den Teams den Kontext und die Klarheit, die sie für die Planung ihrer Arbeit und die Einhaltung ihrer Fristen benötigen.

User Stories werden von Entwicklungsteams während eines Workflows oder Sprints herangezogen, um Aufgaben fertigzustellen und Scope Creep zu verhindern. Große User Stories werden bei Bedarf in mehrere Sprints oder Epics aufgeteilt. Epics sind große User Stories, die in mehrere kleinere Teile unterteilt werden. Mehrere Epics bilden eine Initiative.

Aufbau und Vorlage einer User Story

Ein klarer Aufbau macht User Stories schneller prüfbar. Statt sofort über Funktionen zu sprechen, trennen Sie zuerst Rolle, Bedarf und Nutzen. So erkennen Sie leichter, ob eine Story verständlich formuliert, zu breit angelegt oder noch nicht nah genug an der tatsächlichen Nutzung beschrieben ist.

Das User-Story-Template

Für die praktische Arbeit hilft eine feste Satzstruktur: «Als [Rolle] möchte ich [Bedarf], damit [Nutzen]». Die Vorlage ist bewusst einfach. Sie hilft Ihrem Team, den erwarteten Nutzen klar zu benennen, bevor Sie über Umsetzung oder technische Details sprechen.

• Rolle: Benennen Sie die Person oder Gruppe, für die die Story gedacht ist.

• Bedarf: Beschreiben Sie die gewünschte Handlung oder Fähigkeit in klarer, fachlicher Sprache.

• Nutzen: Formulieren Sie den konkreten Mehrwert, den die Rolle daraus zieht.

Woran Sie einen klaren Aufbau erkennen

Ein guter Aufbau bleibt knapp, konkret und verständlich. Wenn eine Story mehrere Nutzergruppen, mehrere Ergebnisse oder mehrere voneinander unabhängige Aufgaben enthält, ist sie meist noch zu groß. Dann lohnt es sich, die Story vor dem Sprint weiter aufzuteilen.

Wie schreibe ich eine gute User Story?

Eine User Story wird in drei Schritten verfasst und repräsentiert die Sichtweise des Endbenutzers.

Die drei Schritte beim Verfassen einer User Story sind:

• Persona: Der Charakter des Endnutzers

• Bedürfnis: Das Ziel, welches die Softwarefunktion für den Endnutzer erreichen soll

• Zweck: Das Ziel, das der Endnutzer mit der Anwendung der Softwarefunktion verfolgt

Ihre User Story sollte alle drei dieser Komponenten enthalten. Im Folgenden wollen wir auf jedes dieser Elemente eingehen, um Ihnen ein besseres Verständnis dafür zu vermitteln, wie Sie eine effektive User Story verfassen.

Schritt 1: Identifizieren Sie die Persona

Identifizieren Sie die Persona des Endnutzers, indem Sie Ihre Zielgruppe untersuchen. Überlegen Sie, wer durch die Softwarefunktion erreicht werden soll.

Im Folgenden stellen wir Ihnen einige Fragen vor, die Sie sich und Ihrem Team bei der Identifizierung der Nutzer-Persona stellen sollten:

• Für wen entwickeln wir diese Softwarefunktion?

• Welche Art von Produktmerkmalen wünscht sich der Endnutzer?

• Was sind die demografischen und psychografischen Merkmale des Endnutzers?

Abhängig von der Größe des Zielpublikums können mehrere Personas in einer bestimmten User Story vorkommen.

Beispiel-Persona: Katrin, eine Projektmanagerin, die 10 Teammitglieder leitet

Schritt 2: Beschreiben Sie die Bedürfnisse

Beschreiben Sie, wie der Endnutzer Ihre Softwarefunktion nutzen wird und warum. Das ist von entscheidender Bedeutung für Ihr Team, damit es erkennt, wie und warum die Zielgruppe Ihre Funktion überhaupt nutzen würde.

Berücksichtigen Sie diese Fragen bei der Analyse der Absichten des Endnutzers:

• Was beabsichtigt der Endnutzer zu erreichen?

• Wie hilft Ihre Softwarefunktion dem Endnutzer, dessen Ziele zu erreichen?

Vermeiden Sie es, sich auf die spezifischen Funktionen zu versteifen. Überlegen Sie stattdessen, wonach der Endnutzer sucht und wie Ihre Software dazu beitragen kann, dass diese Ziele erreicht werden.

Beispiel für ein Bedürfnis: Den Teammitgliedern dabei helfen zu erkennen, wie einzelne Aufgaben zu größeren Unternehmenszielen beitragen

Schritt 3: Definieren Sie den Zweck

Definieren Sie den Zweck, indem Sie das größere Gesamtbild der Softwareversion analysieren. Überlegen Sie, wie die Softwarefunktion zu Ihren internen Zielen passt.

Sie können sich die folgenden Fragen stellen, um den Zweck näher zu definieren:

• Was ist der Mehrwert der Softwarefunktion?

• Was ist das Problem, das gelöst werden soll?

• Wie passt das zu den übergeordneten Zielen?

Hier soll der Wert Ihrer Softwarefunktion in Bezug auf die übergeordneten Ziele definiert werden.

Beispiel: Steigerung der Effizienz durch klare Vorgaben

Beispiele für User Stories

Die folgenden drei Beispiele zeigen, wie User Stories in verschiedenen Szenarien formuliert werden können:

User-Story-Beispiel 1: Produktentwicklung

• Als Produktmanager wünsche ich mir eine Möglichkeit für Teammitglieder, die Bedeutung einzelner Aufgaben für größere Unternehmensziele zu erkennen, um so auch die Effizienz zu steigern.

User-Story-Beispiel 2: Kundenerfahrung

• Als Stammkunde erwarte ich, dass meine Daten gespeichert werden, um die Kaufabwicklung zu vereinfachen.

User-Story-Beispiel 3: Mobile Apps

• Als Vielnutzer von Apps möchte ich relevante Informationen so schnell wie möglich abrufen können.

Tipps zur Erstellung einer effektiven User Story

Zusätzlich zu den drei oben skizzierten Schritten sollte eine effektive User Story den 3 Cs und dem Akronym INVEST folgen. Mit diesen beiden Elementen können Sie Ihre User Stories wesentlich verbessern.

Die 3 Cs

Die 3 Cs stehen für Card, Conversation und Confirmation. Sie gliedern jede User Story in drei Benchmarks für einen strukturierteren Ablauf:

• Card (Karte): Eine detaillierte Beschreibung der User Story, die für die Sprintplanung genutzt wird. Um Story Cards zu erstellen und mit anderen zu teilen, verwenden Sie am besten ein Work Management Tool.

• Conversation (Austausch): Der Austausch zwischen Kunden, Nutzern und Entwicklern über die Wichtigkeit und mögliche Lösungen der User Story.

• Confirmation (Bestätigung): Eine Vereinbarung zwischen den Beteiligten, dass die Ziele und Lösungen der User Story erfüllt wurden.

INVEST

INVEST steht für Independent, Negotiable, Valuable, Estimable, Small und Testable. Diese Kriterien helfen Ihnen, bessere Stories zu schreiben:

• Independent (Unabhängig): Eine User Story sollte unabhängig sein, d. h. sie ist nicht von anderen Aufgaben abhängig und ist in sich abgeschlossen, steht also für sich.

• Negotiable (Verhandelbar): Eine User Story sollte verhandelbar sein. Das heißt, sie lässt Spielraum für Diskussionen.

• Valuable (Wertvoll): Eine User Story sollte dem Endnutzer einen Mehrwert bieten und Sie Ihren größeren langfristigen Zielen näher bringen.

• Estimable (Abschätzbar): Eine User Story sollte auf eine Weise abschätzbar sein, die gewährleistet, dass sie in einen Sprint passt und sich auf die richtigen Prioritäten konzentriert.

• Small (Überschaubar): Eine User Story sollte eine überschaubare Aufgabe sein, die in kurzer Zeit erledigt werden kann.

• Testable (Prüfbar): Eine Story sollte Akzeptanztests durchlaufen und vorgegebenen Akzeptanzkriterien gerecht werden, um ihre Qualität zu prüfen.

Akzeptanzkriterien für User Stories

Akzeptanzkriterien ergänzen eine User Story um überprüfbare Erwartungen. Sie beschreiben nicht die gesamte Lösung, sondern die Bedingungen, die erfüllt sein müssen, damit das Team die Arbeit verlässlich abnehmen kann.

So formulieren Sie klare Akzeptanzkriterien

• Beschreiben Sie beobachtbares Verhalten statt vager Absichten.

• Grenzen Sie den Umfang klar ein, damit alle Beteiligten dieselbe Erwartung haben.

• Formulieren Sie Kriterien so konkret, dass Entwicklung, Produktverantwortliche und Qualitätssicherung sie gleich auslegen können.

• Prüfen Sie, ob jedes Kriterium wirklich zur Story gehört und nicht eine eigene Story werden sollte.

Kurzes Beispiel

Geht es in einer Story etwa darum, Kundendaten zu speichern, können die Akzeptanzkriterien festhalten, welche Felder Pflicht sind, wann eine Bestätigung angezeigt wird und was bei fehlerhaften Eingaben passieren soll. So wird aus einer allgemeinen Anforderung eine klare Arbeitsgrundlage.

User Stories bewerten und priorisieren

Nicht jede User Story gehört sofort in den nächsten Sprint. Damit Ihr Team mit der wichtigsten Arbeit beginnt, bewerten Sie Stories nach Nutzen, Aufwand, Risiko, Abhängigkeiten und zeitlicher Dringlichkeit.

Nach Nutzen und Aufwand priorisieren

Eine einfache Priorisierung bewertet zuerst Nutzen und Aufwand: Welches Problem lösen wir für wen, und wie groß ist der erwartete Nutzen? Danach prüfen Sie, wie aufwendig die Umsetzung ist. Diese Einordnung hilft Ihrem Team, sinnvolle Reihenfolgen für Product Backlog, Sprint-Planung und Releases festzulegen.

• Hoher Nutzen und geringer Aufwand gehören meist früh in die Planung.

• Hoher Nutzen und hoher Aufwand brauchen oft eine genauere Aufteilung.

• Geringer Nutzen sollte nur dann priorisiert werden, wenn klare Abhängigkeiten bestehen.

Praxisbezug aus der Produktentwicklung

Die Kundenstory von Zenegy zeigt, warum diese Einordnung wichtig ist. Das cloudbasierte Lohnbuchhaltungssystem stand vor der Herausforderung, ohne klare Struktur schnell skalieren zu müssen. Arbeit wurde per E-Mail, in Meetings und im Chat koordiniert, mit fehlender Verantwortlichkeit als Folge.

Durch die Einführung von Asana als flexibles Work-Management-System verknüpfte Zenegy Sprint-Planung, Product Roadmap und Unternehmensprioritäten miteinander. Das Ergebnis: Die Entwicklungsabteilung wuchs auf das Fünffache, während alle Beteiligten auf die Product Roadmap ausgerichtet blieben.

Gerade in wachsenden Teams schafft diese Verbindung mehr Klarheit darüber, welche Stories zuerst umgesetzt werden sollten und wer dafür verantwortlich ist. Ein flexibles Work-Management-System kann diesen Zusammenhang sichtbar machen, sodass Ihr Team Anforderungen nicht isoliert bewertet, sondern im Kontext von Prioritäten, Verantwortlichkeiten und geplanter Arbeit.

Die Wichtigkeit einer präzisen User Story

Das effektive Verfassen von User Stories mag wie ein kleiner Teil im Rahmen einer Produktentwicklung erscheinen. Tatsächlich aber tragen diese Stories dazu bei, neue Produktfunktionen auf kreative Art und Weise auszuarbeiten. Die Liebe zum Detail ist sehr wichtig, denn sie hilft Ihnen, die Bedürfnisse der Nutzer wirklich zu berücksichtigen und entsprechend umzusetzen.

Im Folgenden sind drei Möglichkeiten aufgeführt, wie das Schreiben präziser User Stories dazu beitragen kann, die Ziele der Nutzer zu verwirklichen:

• Der Kunde steht im Mittelpunkt: User Stories stellen die Endnutzer in den Mittelpunkt des Geschehens. Ein wichtiger Bestandteil des AgileFramework. So kann Ihr Team die Bedürfnisse der Nutzer priorisieren und sich auf Möglichkeiten zur Optimierung der Nutzererfahrung konzentrieren.

• Innovative Lösungen vorantreiben: Je tiefer Sie in die Persona Ihrer Endnutzer eintauchen, desto innovativer werden Ihre Softwarelösungen. Das liegt daran, dass Sie sich ganz auf die Bedürfnisse Ihrer Nutzer fokussieren, die Sie wiederum mit Ihren internen Unternehmenszielen in Einklang bringen können. Je besser Sie den Nutzertyp verstehen, auf den Sie sich beziehen, desto effektiver werden Ihre Ergebnisse sein.

• **Fördern Sie die Zusammenarbeit im Team:**Die Zusammenarbeit am Arbeitsplatz wird gefördert, wenn mehrere Teammitglieder die User Stories miteinander besprechen und nach Prioritäten ordnen. Dies bringt mehrere Standpunkte an den Tisch und eröffnet neue Lösungen für bestehende Hindernisse. Von testbaren Ergebnissen bis hin zum besseren Verständnis der Produktanforderungen, je mehr Ihr Team sich untereinander austauscht, desto einfacher wird es sein, die gewünschten Ergebnisse zu erzielen.

Wenn Sie Updates konsequent aus der Sicht des Nutzers betrachten, verbessern Sie den gesamten Prozess der Erhebung von Anforderungen.

Wie das in der Praxis aussehen kann, zeigt das Beispiel von Zenegy. Das Unternehmen stand vor der Aufgabe, sein Produkt- und Entwicklungsteam schnell zu skalieren. Die Koordination über E-Mail und Chat fehlte an Struktur. Durch den Einsatz von Asana verknüpfte Zenegy seine Sprint-Pläne direkt mit der Product Roadmap. So wuchs die Entwicklungsabteilung auf das Fünffache, bei gleichzeitiger Ausrichtung aller Beteiligten auf gemeinsame Ziele. Wenn auch Ihr Team User Stories, Prioritäten und Zusammenarbeit an einem Ort bündeln möchte, bietet Asana die passende Grundlage dafür: Projektmanagement mit Asana entdecken.

Häufig gestellte Fragen zu User Stories

Was ist der Unterschied zwischen einer User Story und einem Use Case?

Eine User Story beschreibt knapp, wer etwas braucht und welchen Nutzen diese Person daraus zieht. Ein Use Case geht deutlich stärker ins Detail und beschreibt Schritt für Schritt, wie eine Interaktion abläuft.

Was ist User Story Mapping?

User Story Mapping ist eine Methode, bei der Sie Stories entlang der Nutzerreise anordnen, um Zusammenhänge, Lücken und sinnvolle Release-Reihenfolgen zu erkennen.

Wie teile ich eine zu große User Story auf?

Teilen Sie große Stories nach Nutzergruppen, Arbeitsschritten, Ausnahmen oder Ergebnissen auf, jede kleinere Story sollte für sich verständlich bleiben und einen klaren Nutzen beschreiben.

Wer schreibt User Stories in Scrum?

Meist verantwortet die produktverantwortliche Person die Formulierung und Pflege der User Stories. Gute Stories entstehen aber in der Praxis oft im Austausch mit Entwicklung, Design und weiteren Beteiligten.

Wenn Sie User Stories, Prioritäten und Sprint-Planung an einem Ort organisieren möchten, können Sie mit Asana starten. Jetzt loslegen.