Als Product Owner sind Sie stets bestrebt dem Kunden/den Stakeholdern am Ende eines Sprints, zur Sprint Review, ein tolles Inkrement präsentieren zu können. Dafür haben Sie eine Reihe von User Stories erstellt, die beschreiben, was Ihree Kunden/Stakeholder brauchen und wie sie davon profitieren. Gemeinsam mit Ihrem Dev-Team haben Sie ein geeignetes Sprintziel definiert und die User Stoires entsprechend geplant, priorisiert, vom Dev-Team schätzen lassen und entsprechend in den jeweiligen Sprint gepackt, so dass Sie mit dem neuen Sprint umgesetzt werden können.
Doch dann passiert es: Der Sprint ist zu Ende, aber einige User Stories sind noch nicht fertig. Vielleicht hat sich das Dev-Team verschätzt, wie viel Arbeit eine User Story erfordert. Vielleicht sind unerwartete Probleme oder Änderungen aufgetreten, die das Team aufgehalten haben. Vielleicht haben Sie nicht genug mit Ihrem Team oder Ihren Stakeholdern kommuniziert, um die Anforderungen klar zu verstehen.
Was machen Sie nun mit diesen offenen User Stories? Wie präsentieren Sie sie im Sprint Review? Wie analysieren Sie sie in der Sprint Retrospektive? Wie planen Sie sie im nächsten Sprint Backlog? Und vor allem: Wie können Sie vermeiden, dass in Zukunft wieder offene User Stories am Ende des Sprints übrig geblieben sind?
Das sind die Fragen, die ich Ihnen gerne in meinem Blogartikel beantworten möchte. Ich möchte Ihnen Möglichkeiten aufzeigen, wie Sie mit offenen User Stories am Ende des Sprints umgehen können und wie Sie sie in Zukunft vermeiden können.
Wie können Sie vermeiden, dass User Stories am Ende des Sprints noch offen sind?
Der beste Weg, um mit offenen User Stories am Ende des Sprints umzugehen, ist natürlich, sie gar nicht erst entstehen zu lassen. Das bedeutet, dass Sie Ihre User Stories richtig schätzen lassen, priorisieren, definieren, überprüfen und ggf. anpassen müssen. Möglicherweise sollten Sie auch die Kommunikation und Zusammenarbeit im Scrum-Team und mit den Stakeholdern überdenken und ggf. verbessern. Hier sind einige Vorschläge wie Sie dies tun können:
- Lassen Sie Ihre User Stories richtig schätzen:
Um zu vermeiden, dass Ihre User Stories unter- oder überschätzt werden, sollten Sie eine geeignete Schätztechnik verwenden. Eine beliebte Technik ist Planning Poker, bei der jedes Teammitglied eine Karte mit einer Zahl auswählt, die die Komplexität der User Story repräsentiert. Die Zahlen werden dann verglichen und diskutiert, bis ein Konsens erreicht wird. Das hilft Ihnen, verschiedene Perspektiven zu berücksichtigen und realistische Schätzungen zu erhalten. - Priorisieren Sie Ihre User Stories:
Damit Sie nicht Gefahr laufen sich in unwichtigen Details zu verlieren oder wichtige Funktionen zu vernachlässigen, sollten Sie Ihre User Stories nach ihrem Wert für den Kunden und ihrem Aufwand für das Team priorisieren. Eine beliebte Technik ist die MoSCoW-Methode, bei der jede User Story als Must have (unverzichtbar), Should have (wünschenswert), Could have (optional) oder Won’t have (nicht relevant) eingestuft wird. Daddurch erhalten Sie die Möglichkeit, Ihre User Stories nach ihrer Dringlichkeit zu ordnen und zu entscheiden, welche Sie im Sprint Backlog aufnehmen wollen. - Definieren Sie Ihre User Stories klar:
Damit keine unklaren oder widersprüchlichen Anforderungen enttstehen oder falsche Annahmen getätigt werden, sollten Sie Ihre User Stories klar definieren und abgrenzen. Eine beliebte Technik ist die INVEST-Methode, bei der jede User Story Independent (unabhängig von anderen), Negotiable (verhandelbar mit den Stakeholdern), Valuable (wertvoll für den Kunden), Estimable (schätzbar vom Team), Small (klein genug für einen Sprint) und Testable (testbar vom Team) sein sollte. So werden Ihre User Stories verständlich und umsetzbar. - Überprüfen und passen Sie Ihre User Stories regelmäßig an:
Um zu vermeiden, dass Sie sich an starre Pläne halten oder wichtige Änderungen ignorieren, sollten Sie Ihre User Stories regelmäßig überprüfen und anpassen. Eine beliebte Technik ist die Definition of Done, bei der Sie festlegen, welche Kriterien eine User Story erfüllen muss, um als fertig zu gelten. Das hilft Ihnen, Ihre User Stories qualitativ hochwertig und konsistent zu machen. Außerdem sollten Sie Ihre User Stories im Daily Scrum, einem täglichen Treffen, bei dem Sie den Fortschritt und die Hindernisse mit Ihrem Team besprichen, aktualisieren. Dadurch werden Ihre User Stories transparent und anpassungsfähig zu machen.
Wie können Sie nun aber mit offenen User Stories am Ende des Sprints umgehen?
Auch wenn Sie stets Ihr Bestes geben, um offene User Stories am Ende des Sprints zu vermeiden, kann es immer noch passieren, dass Sie welche haben. Das ist kein Weltuntergang, denn es kann verschiedenste Gründe haben, warum User Stories nicht fertig umgesetzt werden konnten. Sie sollten diese User Stories aber nicht einfach in den nächsten Sprint ziehen, sondern schauen, was die Gründe waren, dass diese User Stories nicht fertig geworden sind. So sollten Sie offene User Stories im Sprint Review präsentieren und Feedback einholen, gemeinsam in der Sprint Retrospektive analysieren und Verbesserungsmaßnahmen ableiten und ggf. im nächsten Sprint Backlog berücksichtigen und/oder neu planen. Hier sind einige Vorschläge/Möglichkeiten wie Sie das machen könnten:
- Präsentieren Sie Ihre offenen User Stories im Sprint Review und holen Sie Feedback ein:
Bei der Sprint Review präsentieren Sie Ihren Kunden und Stakeholdern grundsätzlich das Ergebnis der geleisteten Arbeit, sprich das, was erfolgreich umgesetzt worden ist. Im Anschluß könnten Sie dem Auditorium bereichten, dass nicht alle User Stories umgesetzt werden konnten und ehrlich begründen, warum sie nicht fertiggeworden sind was du bisher gemacht hast und was du noch machen musst. Du solltest auch Feedback von den Stakeholdern einholen, ob sie mit dem Fortschritt zufrieden sind, ob sie Änderungen wünschen oder ob sie Fragen haben. Das hilft dir, das Vertrauen und die Zufriedenheit der Stakeholder zu erhalten oder wiederherzustellen. - Analysieren Sie offenen User Stories im Sprint Retrospektive und leiten Sie
Verbesserungsmaßnahmen ab: Der Sprint Retrospektive ist ein Treffen am Ende des Sprints, bei dem du mit deinem Team reflektierst, was gut gelaufen ist und was nicht. Du solltest dabei nicht nur deine Erfolge feiern, sondern auch deine Probleme identifizieren. Du solltest dabei herausfinden, warum einige User Stories noch offen sind, was die Ursachen dafür sind und wie du sie in Zukunft vermeiden kannst. Du solltest auch Verbesserungsmaßnahmen für den nächsten Sprint definieren und vereinbaren. Das hilft dir, aus deinen Fehlern zu lernen und deine Scrum-Praxis zu verbessern. - Berücksichtigen Sie offenen User Stories im nächsten Sprint Backlog und planen Sie sie neu:
Der nächste Sprint Backlog ist eine Liste von User Stories, die du im nächsten Sprint umsetzen willst. Du solltest dabei nicht nur neue User Stories aufnehmen, sondern auch deine offenen User Stories berücksichtigen. Du solltest dabei überprüfen, ob sie noch relevant sind, ob sie noch die gleichen Anforderungen haben oder ob sie geändert werden müssen. Du solltest auch schätzen, wie viel Zeit du noch brauchst, um sie fertigzustellen. Du solltest dann entscheiden, ob du sie in den nächsten Sprint Backlog aufnimmst oder nicht. Das hilft dir, deine Planung anzupassen und deine Prioritäten zu setzen.
Fazit: Erfolgreiches Handling von offenen User Stories
In der Welt von Scrum und Agile gibt es keine einheitliche Lösung für offene User Stories am Ende eines Sprints. Der Schlüssel liegt in der kontinuierlichen Verbesserung und der Anpassung an die spezifischen Bedürfnisse deines Teams und deines Projekts. Das Verständnis der Gründe für offene User Stories, die Priorisierung, die technische Lösung und die transparente Kommunikation sind wesentliche Best Practices, die Scrum-Teams bei der Bewältigung dieses Dilemmas unterstützen.
Egal, ob Sie ein Neuling oder ein erfahrener Scrum-Master oder Agile Coach sind, die Kunst der Anpassung und kontinuierlichen Verbesserung ist der Schlüssel zur erfolgreichen Bewältigung von Herausforderungen in der agilen Welt. Denken Sie daran, dass Scrum ein flexibles Framework ist, das dir die Werkzeuge und Prinzipien bietet, um auf Veränderungen zu reagieren und kontinuierlich zu lernen.
In jedem Fall sollten Sie immer bedenken, dass Agilität mehr ist als nur eine Methode – es ist eine Denkweise. Offene User Stories am Ende eines Sprints sind nur eine von vielen Herausforderungen auf dem Weg zur kontinuierlichen Verbesserung. Mit den richtigen Ansätzen und einer agilen Denkweise können Sie diese Hürden erfolgreich überwinden.