Während der Umsetzung einer User Story bemerkt der Entwickler, dass zuvor eine weitere Story umgesetzt werden muss, die für einen späteren Sprint eingeplant ist, was den gesamten Sprintplan durcheinanderbringt. Abhilfe schafft ein frühzeitiges Prüfen der Storys auf gegenseitige Abhängigkeiten.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Während der Umsetzung einer User Story bemerkt der Entwickler, dass zuvor eine weitere Story umgesetzt werden muss, die für einen späteren Sprint eingeplant ist, was den gesamten Sprintplan durcheinanderbringt. Abhilfe schafft ein frühzeitiges Prüfen der Storys auf gegenseitige Abhängigkeiten.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
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 StoryIn 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). 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:
Und so sieht dieses Schema aus: "Als <Benutzerrolle> will ich <das Ziel>, sodass <Grund für das Ziel>." |
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.
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.
Erster Monat kostenlos,
dann 24,95 € pro Monat
Know-how von über 1.000 Profis
Methoden für alle Aufgaben
Websessions mit Top-Expert:innen
Wie wäre es mit Impact Mapping und Story Mapping
30.09.2020
Hallo Herr Bohinc,
Abhängigkeiten zu erkennen und zu visualisieren ist ohne User Stories noch schwieriger. Die User Stories machen es aber einem viel leichtern.
Ich habe vor einigen Jahren einen Artikel von Frau Dr. Monika Schubert gelesen und daraufhin endlich den roten Faden für mich gefunden. Wie ich Impact Mapping und Story Mapping nutze, erfahren Sie hier:
https://www.projektmagazin.de/artikel/agile-festpreisprojekte-der-praxi…
Meines Erachtens ist das eine grundsätzlich wichtige Basis für die Strukturierung des Backlogs über Epics hinaus.
Sie sind sehr schnell über die Methode Story Map hinweggegagen.
Und die 5 Abhängigkeiten sollte nicht der PO dem ScM addressieren. Das passiert m.E. im Backlog Refinement zwischen PO und Dev-Team. Die Priorisierung ist ja auch Aufgabe des PO und er sollte auf die Anzeige von "Extra-Aufwänden" des Teams achten, wenn sich durch eine andere Reihenfolge Kosten sparen lassen. Und sei es durch eine Schulung.
Er verwaltet das Geld und lässt sich durch das Dev-Team beraten. Entscheiden tut er aber selber und dann ist vor dem Sprint alles schon klar.
Beste Grüße
Tassilo Kubitz
Gute Hinweise
02.10.2020
Vielen Dank Herr Kubitz für Ihre Hinweise!
Es ist gut, dass Sie auf Ihren lesenswerten Artikel hingewiesen haben, in dem Sie Ihre Möglichkeit Abhängigkeiten zu managen dargestellt haben.
Meine Intention für diesen Tipp war, auf das Thema der Abhängigkeiten hinzuweisen und dem Leser Ansätze für die Dokumentation dieser Abhängigkeiten aufzuzeigen. Jedes Projekt muss für sich entscheiden. wie Abhängigkeiten dokumentiert und gemanagt werden. In einigen Fällen, wie in dem der Story Map, reicht dann die Beschreibung im Tipp sicher nicht aus. Aber gerade im Beispiel der Story Map gibt es weitere Literatur. Agile Projekte, die mit Jira arbeiten, müssen sich ebenfalls intensiv mit dem Tool beschäftigen, wenn Sie dies für die Dokumentation von Abhängigkeiten nutzen wollen.
Ich stimme Ihnen vollkommen zu, dass der Produkt Owner für die Abhängigkeiten zuständig ist. Wenn ich im Tipp geschrieben habe, dass der Produkt Owner Abhängigkeiten beim Scrum Master adressiert, so ist damit gemeint, dass er diesen über die Abhängigkeiten informiert, damit er mit darauf achtet, dass die Abhängigkeiten beseitigt werden. In dem Fall, dass eine Abhängigkeit ein Impediment ist, gehört die Beseitigung der Abhängigkeit sogar zu seinen Aufgaben.
Der Tipp sollte keine Methodenbeschreibung im Umgang mit Abhängigkeiten bei User Stories sein. Ein Beispiel für einen Leitfaden für die Beseitigung von Abhängigkeiten ist in der in der Literatur aufgeführten Bachelorarbeit von Gabrijela Juresik beschrieben.
Tomas Bohinc