User Story Slicing in Agilen Projekten: Darauf kommt es an!

In agilen Projekten steht das schnelle und wertorientierte Liefern von Funktionalität im Mittelpunkt. Dabei sind User Stories ein wichtiges Hilfsmittel, um Anforderungen zu definieren. Doch oft sind diese Stories anfangs zu groß, komplex oder unscharf formuliert. Die Lösung? Story Slicing, also das Zuschneiden von User Stories. In diesem Blogartikel erfährst du, worauf es beim Zuschneiden von Stories ankommt, welche Techniken sich bewährt haben und wie du dabei am besten vorgehst.

Große User Stories – auch „Epics" genannt – sind schwer zu planen, zu schätzen und zu entwickeln. Sie führen oft zu langen Entwicklungszyklen und verzögern das Feedback vom Kunden. Beim Story Slicing geht es darum, komplexe Stories in kleinere, umsetzbare Einheiten zu teilen, die in einem Sprint abgeschlossen werden können. Dadurch wird der Fortschritt sichtbarer und die Zusammenarbeit im Team effektiver.

Wer ist für das Slicing zuständig?

Im Scrum ist das Slicing (also das Zerschneiden) von User Stories in kleinere, handhabbare Teile primär eine Aufgabe des Scrum-Teams, wobei die Product Ownerin oder der Product Owner sowie das Entwicklungsteam eine zentrale Rolle spielen:

1. Product Owner (PO): Der PO ist für die Verwaltung und Priorisierung des Product Backlogs verantwortlich. Dazu gehört auch, die User Stories so zu formulieren und vorzubereiten, dass sie für das Team verständlich sind und den Produktwert maximieren. Wenn es darum geht, eine User Story in kleinere, wertvolle Teile zu unterteilen, arbeitet der PO eng mit dem Team zusammen und bringt das fachliche Verständnis für das Produkt ein.
2. Entwicklungsteam: Das Entwicklungsteam bringt die technische Expertise ein und kann am besten einschätzen, welche Teile einer User Story sinnvollerweise getrennt umgesetzt werden können, um im Sprint abgeschlossen zu werden. Gemeinsam mit dem PO besprechen sie, wie große User Stories so geschnitten werden können, dass sie innerhalb eines Sprints umsetzbar und gleichzeitig wertvoll für das Produkt sind.
3. Scrum Master: Der Scrum Master moderiert und unterstützt den Prozess, sorgt dafür, dass das Team effiziente Methoden für das Slicing einsetzt und dass die Prinzipien und Werte von Scrum beachtet werden. Die eigentliche inhaltliche Aufteilung von Stories ist jedoch nicht die Aufgabe des Scrum Masters.

Beim Story Slicing ist es wichtig, sich an einige Grundprinzipien zu halten:

1. Jede User Story sollte einen Mehrwert liefern
   Auch eine kleinere Story muss einen sichtbaren Nutzen für den Benutzer bringen. Vermeide, dass Stories in technische oder „unsichtbare" Aufgaben zerfallen, die für den Endnutzer keinen direkten Wert haben.
2. Vermeide zu große Stories, die nicht in einem Sprint fertiggestellt werden können
   Ziel ist es, Stories in der Größe so anzupassen, dass sie innerhalb eines Sprints (üblicherweise 1-2 Wochen) fertiggestellt werden können.
3. Konzentriere dich auf das MVP (Minimum Viable Product) der Story
   Jede Story sollte die minimal notwendige Funktionalität bieten, um den User-Anforderungen gerecht zu werden.
4. Denke aus der Benutzerperspektive
   Der Fokus sollte stets auf den Bedürfnissen des Benutzers liegen und wie die Story zu seiner Zufriedenheit und zum Erfolg des Produkts beiträgt.

Es gibt verschiedene Techniken, um Stories in sinnvollere, kleinere Teile zu zerlegen. Hier sind einige bewährte Methoden:

• Beispiel: Wenn die Story lautet „Als Benutzer möchte ich ein Profil anlegen, damit ich meine Daten speichern kann", könnte man dies in folgende Stufen unterteilen:
  • Profil erstellen (nur Eingabemaske)
  • Profil speichern (Datenbankanbindung)
  • Profil bearbeiten (Änderungen vornehmen)
• Vorteil: Jede Stufe liefert einen eigenen Mehrwert und kann unabhängig getestet werden.

• Jede User Story hat bestimmte Akzeptanzkriterien. Betrachte jedes dieser Kriterien als eigene Mini-Story.
• Beispiel: Die Story „Ein Benutzer kann eine Datei hochladen" könnte Kriterien wie „Datei wird gespeichert", „Dateiformat wird geprüft", „Maximalgröße wird eingehalten" enthalten. Jedes dieser Kriterien könnte als einzelne Story formuliert und umgesetzt werden.

• Manchmal macht es Sinn, eine Story entlang der Architektur-Ebenen zu teilen: z. B. Backend- und Frontend-Implementierung.
• Beispiel: Die Story „Als Benutzer möchte ich eine Liste meiner Artikel sehen" könnte in eine Backend-Story (Datenbankabfrage) und eine Frontend-Story (Anzeigen der Artikel) geteilt werden.
• Achtung: Hier ist der Benutzerwert eingeschränkt, daher empfiehlt sich diese Methode nur, wenn andere Methoden nicht möglich sind.

(Bildidee: Schichtenmodell eines Software-Stacks, in Backend- und Frontend-Teile zerlegt)

• Starte mit dem sogenannten Happy Path, also dem idealen Verlauf ohne Fehler. Später kannst du Randfälle (z. B. Fehlerfälle) als separate Stories behandeln.
• Beispiel: Eine Story „Der Benutzer kann sich einloggen" könnte zunächst nur den Happy Path (Login mit korrekten Daten) umfassen, während Fälle wie „falsches Passwort" oder „Konto gesperrt" als separate Stories behandelt werden.

1. Story verstehen: Besprich die User Story im Team und stelle sicher, dass alle den Nutzen und die Anforderungen verstehen.
2. Slicing-Methode auswählen: Überlege, welche der oben genannten Methoden am besten passt.
3. Story in kleine, eigenständige Einheiten aufteilen: Erstelle pro Einheit eine neue, eigenständige Story.
4. Prüfen und schätzen: Schätze die neuen Stories und prüfe, ob sie jeweils in einem Sprint abgeschlossen werden können.
5. Rücksprache mit dem Product Owner: Stelle sicher, dass der Product Owner mit den neuen Stories einverstanden ist und sie den gewünschten Mehrwert liefern.

Implizite Anforderung in explizite Storys aufteilen:

Team Schätzung: sehr genau da sehr detailliert. Die Einzelnen Storys passen aber nicht in einen Sprint. (28SP) Vorteil: Es kann leicht ein kritischer Pfad identifiziert werden, der für das Erreichen der Sprintziels ausschlaggebend ist. (Rot dargestellt)

Endgültige Schneidung 

Alle zum Erreichen des Sprint Ziels erforderlichen UserStorys sind in einem Sprint. Die optionalen UserStorys können in den nächsten Sprint gezogen werden. Der Vorteil ist, das die Story schon getestet werden kann und ggf. auch ausgeliefert werden kann, da dieFunktionalität sicher gestellt ist. 

Zusammenfassung

Story Slicing hilft Teams, fokussierter, effizienter und wertorientierter zu arbeiten. Indem komplexe User Stories in kleinere, eigenständige Teile zerlegt werden, wird der Fortschritt sichtbarer und das Feedback schneller integriert. Verwende die beschriebenen Techniken, um auch in deinem Team die User Stories sinnvoll und nachhaltig zuzuschneiden.