User Storys sollten voneinander unabhängig sein, damit jede Story jederzeit in einem Sprint umgesetzt werden kann. Jedoch haben die Abhängigkeiten zwischen Storys (z.B. inhaltlich oder zeitlich) in den vergangenen Jahren zugenommen, weil Softwareanwendungen immer komplexer werden und Agile Methoden auch in Themenfeldern eingesetzt werden, die schwierig zu modularisieren sind. Ein Beispiel ist das Service-Management, bei dem Teams komplexe Kunden-Probleme gemeinsam lösen müssen.

Häufig bleiben Abhängigkeiten bis zur Umsetzung der Story in einem Sprint unerkannt und verursachen dadurch Probleme. Im schlimmsten Fall können Abhängigkeiten sogar zum Risiko für das Projekt werden, wenn das Projektteam diese nicht selbst beseitigen kann und es trotzdem mit der Realisierung einer abhängigen User Story beginnt.

Je mehr User Storys voneinander abhängig sind, umso wichtiger ist es, alle Abhängigkeiten nachzuvollziehen und sie den Beteiligten transparent zu machen. Nur so können Sie diese systematisch beseitigen. Dieser Beitrag zeigt, wie das Scrum Team und hier insbesondere der Produkt Owner (als der Verantwortliche für das Produkt Backlog) Abhängigkeiten von User Storys aufzeigen, dokumentieren und ihre Beseitigung steuern können.

Das Konzept der User Story In einer User Story formuliert der Anwender eine Anforderung an eine Software. Nach den Konzepten von Extreme Programming, Scrum usw. werden User Storys (siehe auch die Methodenbeschreibung) auf Karten dokumentiert, sogenannten Story Cards (siehe Bild 1). Wir empfehlen zum Thema Agile Methoden 4 x 4 Stunden 25.09.2025 1195,- Die 5 wichtigsten agilen Praktiken effektiv einsetzen In 4 Workshops stellen wir Ihnen die Big Five der agilen Praktiken vor und stellen gemeinsam mit Ihnen Ihren agilen Werkzeugkoffer zusammen – ganz nach den Anforderungen Ihrer Projektumgebung.  Mehr Infos Der Berater für agile Softwareentwicklung und Autor Mike Cohn beschreibt in seinem Buch "User Storys Applied for Agile Software Development" (ein Klassiker zum Thema) ein einfaches Schema, um eine User Story kurz und aussagekräftig zu formulieren. Diesem Schema zufolge besteht eine Story lediglich aus einem Satz, der die folgenden drei Fragen beantwortet: Wer stellt die Anforderung? Was soll realisiert werden? Warum soll es realisiert werden? Und so sieht dieses Schema aus: "Als <Benutzerrolle> will ich <das Ziel>, sodass <Grund für das Ziel>."

Beispiele für Abhängigkeiten bei User Storys

Beispiel 1: Als Nutzer der Anwendung will ich mich bei der Anwendung registrieren können, damit ich diese verwenden kann.

Beispiel 2: Als Nutzer der Anwendung will ich mich bei der Anwendung anmelden können, damit ich diese verwenden kann.

Vermutlich ist Ihnen aufgefallen, dass diese beiden User Storys voneinander abhängig sind: Die zweite User Story kann erst programmiert werden, wenn die erste umgesetzt ist, weil erst dann feststeht, welche Daten für eine Anmeldung abgefragt werden können. Nachfolgend erfahren Sie, welche Gründe für Abhängigkeiten es gibt und wie Sie diese erkennen und dokumentieren können.

Alle Abhängigkeiten frühzeitig erkennen

Zum Problem wird eine Abhängigkeit, wenn sie zu spät erkannt wird. Während eines laufenden Sprints z.B. fehlt die Zeit, um eine solche zu beseitigen. Vermeiden können Sie dies, indem Sie Abhängigkeiten bereits erkennen und dokumentieren, wenn die User Storys in den Product Backlog eingestellt werden. Achten Sie als Produkt Owner schon bei der Erstellung des Backlog auf Abhängigkeiten unter User Storys und dokumentieren Sie diese. Sprechen Sie mit dem Team und dem Scrum Master ab, wie Sie User Storys dokumentieren und wann Sie diese besprechen, damit für jeden Beteiligten klar ist, wann, wie und durch wen Abhängigkeiten zwischen User Storys beseitigt werden.

5 Gründe für Abhängigkeiten zwischen User Storys