Roland Kompalka
Oktober 23, 2024

User Stories – Schreiben & Schneiden

Inhaltsverzeichnis

User Stories sind ein zentrales Werkzeug in der agilen Entwicklung, um Anforderungen klar und nutzerorientiert zu formulieren. In diesem Beitrag erfährst du, wie du effektive User Stories schreibst – von der richtigen Struktur bis hin zu klaren Akzeptanzkriterien. Dabei helfen dir agile Werte und Prinzipien als Leitfaden, wie der Fokus auf Kundennutzen, Flexibilität und kontinuierliche Wertschöpfung. Zudem wird erläutert, warum das Schneiden großer User Stories entscheidend ist, um agil zu bleiben. Praktische Methoden wie das I.N.V.E.S.T.-Prinzip und S.P.I.D.R.helfen dir, Stories handhabbar und wertorientiert zu gestalten.

User Stories im Überblick

User Stories sind ein zentrales Werkzeug in agilen Projekten, aber warum verwenden wir sie überhaupt? Ihr Wert liegt nicht nur in der Dokumentation von Anforderungen, sondern vielmehr darin, den Fokus auf den Kunden und dessen Bedürfnisse zu richten. Sie schaffen ein gemeinsames Verständnis im Team und dienen als Basis für Diskussionen. Anstatt komplexe Spezifikationen zu verfassen, bringen User Stories den Mehrwert eines Produkts oder einer Funktion auf den Punkt: Was will der Nutzer und warum ist das wichtig?

Typischerweise folgt eine User Story einer einfachen Struktur: „Als [Rolle] möchte ich [Ziel], um [Nutzen] zu erreichen.“ Diese Klarheit hilft dir und deinem Team, sich auf den Mehrwert für den Endnutzer zu konzentrieren, anstatt sich in technischen Details zu verlieren. Aber User Stories sind mehr als nur Text – sie sind eng mit dem Product Backlog verbunden und bilden die Grundlage für Priorisierungen, Sprintplanungen und die tägliche Zusammenarbeit im agilen Prozess.

User Stories führen das Team und die Stakeholder zusammen und ermöglichen es, Anforderungen greifbar zu machen. Sie sind das Rückgrat eines agilen Backlogs und sorgen dafür, dass alle Beteiligten den Kunden im Blick behalten.

User Stories schreiben

Das Schreiben von User Stories erfordert nicht nur Kreativität, sondern auch Struktur. Damit User Stories wirklich effektiv sind, müssen sie klar, präzise und auf den Punkt gebracht sein. Aber wie genau formulierst du eine gute User Story, die deinem Team hilft, den Fokus auf den Kunden und dessen Bedürfnisse zu richten?

Bestandteile einer User Story

Jede User Story, wie du sie in Tools wie Jira findest, enthält drei wesentliche Bestandteile: einen Namen, eine Beschreibung und Akzeptanzkriterien. Der Name dient als prägnante Referenz, die das Ziel oder den Nutzen der Story zusammenfasst, sodass du und dein Team schnell erfassen könnt, worum es geht. Die Beschreibung gibt im klassischen User-Story-Format einen Überblick über die Anforderung aus der Perspektive des Nutzers: „Als [Rolle] möchte ich [Ziel], um [Nutzen].“ Damit bleibt der Kundennutzen stets im Fokus. Die Akzeptanzkriterien schließlich definieren klare Bedingungen, die erfüllt sein müssen, damit die Story als abgeschlossen gilt. Diese Kriterien stellen sicher, dass alle Beteiligten dasselbe Verständnis von der Umsetzung und dem erwarteten Ergebnis haben.

Einen guten Namen formulieren

Der Name einer User Story mag simpel erscheinen, aber er spielt eine größere Rolle, als du vielleicht denkst. Ein guter Name muss verständlich, prägnant und einprägsam sein. Er dient als Kurzreferenz, sowohl im täglichen Arbeiten als auch bei Diskussionen. Wenn du eine User Story benennst, versuche, den Hauptnutzen oder die Kernfunktion in den Vordergrund zu stellen. Namen wie „Benutzerkonto erstellen“ oder „Artikel zur Wunschliste hinzufügen“ sind klar und präzise. Vermeide zu lange oder technisch komplizierte Titel, da sie unnötig Verwirrung stiften können.

User Stories formulieren: Das User-Voice-Format

Das „User-Voice-Format“ („Als [Rolle] möchte ich [Ziel], um [Nutzen] zu erreichen“) ist eine bewährte Methode, User Stories zu formulieren. Es hilft dir, die Perspektive des Nutzers einzunehmen und sorgt dafür, dass die Story einen klaren Mehrwert vermittelt. Statt allgemeine oder technische Anforderungen zu beschreiben, zwingt dieses Format dich dazu, das Ganze aus der Sicht des Endnutzers zu sehen. Dadurch entstehen Storys, die nicht nur umsetzbar, sondern auch wertvoll sind.

Beispiel: „Als registrierter Benutzer möchte ich mein Passwort ändern, um meine Kontosicherheit zu erhöhen.“
Hier wird deutlich, wer die Handlung ausführt (der registrierte Benutzer), was getan werden soll (Passwort ändern) und warum (Kontosicherheit erhöhen).

Es beantwortet die Fragen: Wer ist der Nutzer? Was möchte er erreichen? Und warum ist das für ihn wichtig?

  • Rolle: Wer ist der Nutzer oder die Zielgruppe, für die du die Story schreibst? Dies kann ein Endkunde, ein interner Anwender oder eine spezifische Stakeholder-Gruppe sein.
  • Ziel: Was möchte dieser Nutzer erreichen? Hier beschreibst du die Handlung oder das Bedürfnis des Nutzers.
  • Nutzen: Warum ist dieses Ziel für den Nutzer von Bedeutung? Was ist der Mehrwert oder die Motivation dahinter?


Durch diese Struktur bleibt der Fokus immer auf dem tatsächlichen Nutzen für den Nutzer, was eine der Kernideen agiler Methoden ist. Es ist nicht nur wichtig, was gebaut wird, sondern vor allem, warum es gebaut wird.

Akzeptanzkriterien formulieren

User Stories alleine reichen nicht aus – sie müssen klar definierte Akzeptanzkriterien haben. Diese Kriterien legen fest, wann eine User Story als „erledigt“ betrachtet wird. Sie beschreiben die genauen Bedingungen, die erfüllt sein müssen, damit die Story als erfolgreich umgesetzt gilt. Ohne Akzeptanzkriterien kann es zu Missverständnissen kommen, ob die Anforderung vollständig oder korrekt umgesetzt wurde.

Akzeptanzkriterien könnten so aussehen:

  • Der Benutzer muss in der Lage sein, ein neues Passwort einzugeben und es zu bestätigen.
  • Eine Fehlermeldung erscheint, wenn die Passwörter nicht übereinstimmen.
  • Das neue Passwort wird erfolgreich gespeichert und der Benutzer erhält eine Bestätigungsmeldung.

Durch klare Akzeptanzkriterien weiß das Entwicklungsteam genau, was geliefert werden muss, und es gibt keine Unsicherheit darüber, wann die Story abgeschlossen ist.

Best Practices – I.N.V.E.S.T & 3Cs

Um sicherzustellen, dass deine User Stories wirklich effektiv sind, gibt es einige Best Practices, die du beachten solltest. Eine bekannte Regel ist die I.N.V.E.S.T.-Regel:

  • Independent (Unabhängig): Die User Story sollte, wenn möglich, unabhängig von anderen Storys umsetzbar sein.
  • Negotiable (Verhandelbar): Sie sollte keine festen Spezifikationen enthalten, sondern Raum für Diskussionen lassen.
  • Valuable (Wertvoll): Jede User Story muss für den Endnutzer einen klaren Mehrwert bieten.
  • Estimable (Schätzbar): Die Story muss ausreichend klar formuliert sein, damit das Team den Aufwand schätzen kann.
  • Small (Klein): Eine gute User Story sollte klein genug sein, um innerhalb eines Sprints umgesetzt zu werden.
  • Testable (Testbar): Die Story muss überprüfbar sein, damit klar ist, ob die Anforderungen erfüllt wurden.

Ein weiteres nützliches Konzept sind die 3Cs von Ron Jeffries:

  • Card (Karte): Jede User Story sollte auf einer Karte (physisch oder digital) dargestellt werden, die die grundlegenden Informationen enthält.
  • Conversation (Gespräch): Die Details der User Story entstehen durch das Gespräch zwischen dem Team und den Stakeholdern.
  • Confirmation (Bestätigung): Die Akzeptanzkriterien dienen als Bestätigung, dass die Story erfolgreich umgesetzt wurde.


Indem du diese Prinzipien anwendest, schreibst du nicht nur gute User Stories, sondern hilfst auch deinem Team, effektiv und zielorientiert zu arbeiten. User Stories bieten einen klaren und kundenorientierten Weg, Anforderungen zu formulieren und sicherzustellen, dass das Entwicklungsteam genau versteht, was benötigt wird und warum es wichtig ist.

User Stories schneiden

Das Schreiben von User Stories ist nur der erste Schritt. Häufig wirst du feststellen, dass deine Story zu groß, zu komplex oder einfach nicht für einen Sprint geeignet ist. Hier kommt das Schneiden von User Stories ins Spiel. Aber warum schneiden wir sie überhaupt, und wie gehst du dabei am besten vor?

Warum schneiden wir User Stories?

Der Hauptgrund, warum wir User Stories schneiden, liegt in den agilen Prinzipien selbst. Agilität bedeutet, dass du schnell auf Veränderungen reagieren und kontinuierlich Wert liefern möchtest. Große User Stories, oft als “Epics” bezeichnet, sind schwer zu schätzen, benötigen zu viel Zeit zur Umsetzung und bringen das Risiko mit sich, den Kundenwert aus den Augen zu verlieren.

Indem du große Stories in kleinere, handhabbare Einheiten zerlegst, kannst du regelmäßig funktionierende Software liefern, dein Team bleibt fokussiert, und du kannst schneller auf Feedback reagieren. Kleine, überschaubare User Stories lassen sich besser priorisieren und ermöglichen es dir, iterativ vorzugehen, was ein zentrales Element agiler Methoden ist.

Agile Prinzipien, die uns erklären, warum wir User Stories schneiden

Einige der agilen Prinzipien verdeutlichen, warum das Schneiden von User Stories so wichtig ist:

  • Kontinuierliche Auslieferung von Wert: Agiles Arbeiten strebt danach, möglichst schnell funktionierende Software zu liefern. Große, monolithische User Stories verzögern dies, da sie lange brauchen, bis sie abgeschlossen sind.
  • Flexibilität und Anpassungsfähigkeit: Wenn du kleinere User Stories hast, kannst du sie leichter priorisieren und anpassen. Das ermöglicht dir, besser auf sich verändernde Anforderungen oder Feedback zu reagieren.
  • Wertorientierung: Kleine, fokussierte Stories stellen sicher, dass du den Blick auf den Mehrwert für den Nutzer nicht verlierst. Das reduziert das Risiko, sich in Details zu verlieren, die keinen direkten Nutzen haben.

Horizontaler vs. Vertikaler Schnitt

Beim Schneiden von User Stories unterscheidest du zwischen horizontalem und vertikalem Schnitt. Es ist wichtig, zu verstehen, welcher Ansatz wann sinnvoll ist.

  • Horizontaler Schnitt: Beim horizontalen Schneiden zerlegst du eine Funktionalität nach Schichten oder technischen Ebenen. Zum Beispiel könnte der horizontale Schnitt die Datenbanklogik von der Benutzeroberfläche trennen. Das Problem dabei ist, dass du dadurch möglicherweise eine User Story hast, die keinen vollständigen Nutzen für den Endnutzer bietet. Daher ist dieser Ansatz oft weniger geeignet, da er zwar technisch sauber wirken mag, aber nicht den agilen Grundsatz der kontinuierlichen Auslieferung von Wert erfüllt.

  • Vertikaler Schnitt: Beim vertikalen Schneiden schneidest du die Story so, dass jede geschnittene Story einen kompletten Durchstich durch das System darstellt – von der Datenbank über die Geschäftslogik bis hin zur Benutzeroberfläche. Auf diese Weise lieferst du mit jeder geschnittenen User Story eine funktionierende, wertvolle Komponente. Der vertikale Schnitt ist der bevorzugte Ansatz, da er sicherstellt, dass jede Story, die du lieferst, sofort Nutzwert bietet.

Schnittmuster nach S.P.I.D.R. – Mike Cohn

Eine bewährte Methode zum Schneiden von User Stories stammt von Mike Cohn und wird als S.P.I.D.R.-Ansatzbezeichnet. Dieser Ansatz bietet dir fünf mögliche Schnittmuster, um große User Stories in kleinere, wertvolle Einheiten zu zerlegen:

  1. Spike (S): Manchmal ist eine User Story zu komplex, um sie sofort zu lösen. In diesem Fall kannst du einen Spike verwenden – eine kurze Forschungsstory, die dir hilft, die Unsicherheit zu reduzieren. Ein Spike dient nicht direkt dazu, Wert zu liefern, sondern schafft Klarheit, wie du die eigentliche Story umsetzen kannst.

  2. Path (P): Wenn deine User Story mehrere alternative Wege hat, um ein Ziel zu erreichen, kannst du sie entlang dieser Pfade schneiden. Zum Beispiel könnte eine Story die Möglichkeit umfassen, eine Funktion auf dem Desktop oder mobil zu nutzen. Jeder dieser Pfade könnte eine separate Story werden.

  3. Interface (I): Eine User Story kann oft anhand verschiedener Schnittstellen geschnitten werden. Wenn dein System sowohl eine API als auch eine Benutzeroberfläche hat, könntest du die Stories so schneiden, dass du zuerst die API entwickelst und dann die Oberfläche.

  4. Data (D): Eine weitere Möglichkeit besteht darin, die Story basierend auf den verschiedenen Datentypen zu schneiden. Zum Beispiel könntest du in einer Story erst die Grunddaten bearbeiten und in einer späteren Story zusätzliche Felder oder komplexere Datentypen hinzufügen.

  5. Rules (R): Komplexe Business-Regeln oder Validierungen können oft in einzelne Stories aufgeteilt werden. Du könntest mit einer einfachen Version der Regel beginnen und schrittweise zusätzliche Regeln hinzufügen.

Dieser Ansatz hilft dir, den Überblick zu behalten und eine Story sinnvoll in kleinere, wertschöpfende Einheiten zu unterteilen.

Schnittmuster von HumanizingWork

Neben dem S.P.I.D.R.-Ansatz gibt es auch Methoden wie die von Humanizing Work, die sich auf den menschlichen Aspekt und die Wertorientierung fokussieren. Sie empfehlen, User Stories so zu schneiden, dass sie immer die „happy path“-Erfahrung des Nutzers abdecken. Du beginnst also mit der grundlegendsten Funktion, die dem Nutzer bereits einen direkten Mehrwert bietet, und erweiterst sie dann schrittweise.

Ein Beispiel wäre die Entwicklung eines Loginsystems. Anstatt sofort jede mögliche Fehlerbehandlung zu implementieren, beginnst du mit der Basisfunktion: „Als Benutzer möchte ich mich mit einem gültigen Passwort anmelden können.“ Danach könntest du die Fehlerbehandlungen wie „Passwort vergessen“ oder „falsches Passwort“ als eigene User Stories schneiden.

Workshop: "User Stories meistern – Vom Schreiben zum Schneiden"

Möchtest du lernen, wie du User Stories nicht nur richtig formulierst, sondern auch effektiv schneidest, um agiler und fokussierter zu arbeiten? In unserem praktischen Workshop bekommst du das nötige Handwerkszeug, um User Stories so zu gestalten, dass sie für dein Team wirklich funktionieren. Du wirst praxisnah erfahren, wie du große und komplexe Anforderungen in handhabbare, wertschöpfende Einheiten zerlegst, die den agilen Prinzipien entsprechen.

Gemeinsam tauchen wir tief in die Methoden ein, die es dir ermöglichen, vom Schreiben über die Strukturierung bis hin zum Schneiden von User Stories alles sicher zu beherrschen. Melde dich an und mach den nächsten Schritt in deiner agilen Praxis!

Hier geht’s zur Anmeldung: https://agilemovement.de/events/user-stories-meistern-vom-schreiben-zum-schneiden/

Fazit

Das Schreiben und Schneiden von User Stories ist weit mehr als nur eine Methode zur Dokumentation von Anforderungen. Es ist ein entscheidender Bestandteil agiler Arbeitsweisen, der sicherstellt, dass dein Team den Fokus stets auf den Kundennutzen und die kontinuierliche Wertlieferung legt. Gut formulierte User Stories ermöglichen es, komplexe Anforderungen verständlich und umsetzbar zu machen. Dabei helfen dir agile Prinzipien wie Transparenz, Zusammenarbeit und Flexibilität.

Das Schneiden großer Stories in kleinere, handhabbare Einheiten fördert die Iterativität und ermöglicht es deinem Team, schnell und effizient zu arbeiten. Du kannst dabei auf bewährte Techniken wie das I.N.V.E.S.T.-Prinzip oder Schnittmuster wie S.P.I.D.R. zurückgreifen, um sicherzustellen, dass jede Story einen klaren Mehrwert bietet und in einem Sprint realistisch umsetzbar ist.

Am Ende geht es darum, dass du und dein Team in der Lage seid, Anforderungen in Form von User Stories so zu strukturieren, dass sie leicht verständlich, testbar und lieferbar sind. Mit den richtigen Tools und einer guten Story-Schnitttechnik stellst du sicher, dass der agile Prozess reibungslos verläuft und sich kontinuierlich an die Bedürfnisse deiner Kunden und die Herausforderungen des Projekts anpasst. Gut geschriebene und geschnittene User Stories sind der Schlüssel zu einem erfolgreichen agilen Workflow und langfristigem Projekterfolg.

 

Die häufigsten Fragen (FAQ)

In Scrum ist eine User Story eine kurze, einfache Beschreibung einer Anforderung aus Sicht des Endnutzers. Sie dient dazu, klarzustellen, was der Nutzer möchte und welchen Mehrwert die Umsetzung bietet. User Stories sind zentrale Bausteine des Product Backlogs und werden im Rahmen der Sprintplanung priorisiert und umgesetzt. Ihr Ziel ist es, den Fokus auf den Mehrwert für den Nutzer zu lenken, anstatt sich in technischen Spezifikationen zu verlieren.

Eine User Story besteht typischerweise aus drei Hauptbestandteilen:

  1. Beschreibung: Im Format „Als [Rolle] möchte ich [Ziel], um [Nutzen] zu erreichen.“
  2. Akzeptanzkriterien: Diese legen fest, wann die Story als fertig gilt und welche Bedingungen erfüllt sein müssen.
  3. Diskussionen/Notizen: Hier werden relevante Details, offene Fragen oder technische Überlegungen dokumentiert, die während der Entwicklung geklärt werden müssen.

Zusätzlich sollte die User Story einen klaren und prägnanten Namen haben, der das Ziel der Story verständlich macht.

Eine gute User Story sollte nach dem I.N.V.E.S.T.-Prinzip gestaltet sein:

  • Independent (Unabhängig): Sie kann unabhängig von anderen User Stories umgesetzt werden.
  • Negotiable (Verhandelbar): Sie bietet Raum für Diskussionen und Anpassungen.
  • Valuable (Wertvoll): Sie bietet dem Endnutzer einen klaren Nutzen.
  • Estimable (Schätzbar): Der Aufwand zur Umsetzung der Story muss realistisch einschätzbar sein.
  • Small (Klein): Sie sollte in einem Sprint abgeschlossen werden können.
  • Testable (Testbar): Es müssen klare Akzeptanzkriterien vorhanden sein, um zu prüfen, ob die Story vollständig umgesetzt wurde.

User Stories sind kurze, einfache Beschreibungen aus der Sicht des Endnutzers und fokussieren sich auf den Mehrwert, den eine Funktion bietet. Sie sind oft weniger detailliert und dienen als Grundlage für Diskussionen im Team.

Use Cases hingegen sind detailliertere Beschreibungen von Interaktionen zwischen einem Benutzer und dem System. Sie umfassen mehrere Szenarien, einschließlich alternativer Abläufe und Fehlerbehandlungen, und sind häufig technischer. Während User Stories meist eher einen Überblick bieten, tauchen Use Cases tiefer in die Funktionalität und Abläufe ein.

Die Definition of Done (DoD) beschreibt, welche Bedingungen erfüllt sein müssen, damit eine User Story als abgeschlossen gilt. Sie legt fest, welche Qualitätsstandards und Anforderungen eine Story erfüllen muss, um als „fertig“ bewertet zu werden. Typische Kriterien in der Definition of Done können sein:

  • Der Code ist fertig implementiert und getestet.
  • Die Akzeptanzkriterien der Story sind erfüllt.
  • Der Code ist dokumentiert und in das Versionskontrollsystem eingepflegt.
  • Die Änderungen sind auf der Entwicklungsumgebung oder dem Produktionsserver bereitgestellt.
  • Der Product Owner hat die Story abgenommen.

Die Definition of Done stellt sicher, dass das Team und die Stakeholder ein gemeinsames Verständnis davon haben, was „fertig“ bedeutet.

Design Thinking Overview
Scrum
Mohamed Messri
Design Thinking Workshop

Design Thinking ist ein Problemlösungsansatz, der Empathie, Kreativität und Zusammenarbeit priorisiert. Wir untersuchen die Bedeutung