scrum, Agile Softwareentwicklung, Agile & Usability

Sprint-Abbruch im Scrum-Team: Ja oder Nein?

Mitunter kommt es in Scrum-Teams vor, dass über den Abbruch eines Sprints nachgedacht wird. Doch wer darf eigentlich über den Sprint-Abbruch entscheiden? Und warum sollte ein Sprint abgebrochen werden können? In diesem Blogbeitrag möchte ich kurz einen Überblick darüber geben, warum es sinnvoll sein kann, einen Sprint abzubrechen und von vorne zu starten. Aber vor allem: Warum es in den meisten Fällen eben nicht gemacht werden sollte.

scrum-board-sprint

Was spricht für einen Sprint-Abbruch?

Ein Sprint darf dann abgebrochen werden, wenn das Sprint-Ziel obsolet geworden ist. Das kann dann der Fall sein, wenn sich beispielsweise die Zielsetzung des Unternehmens maßgeblich geändert hat. Die Fortführung des Sprints macht auch dann unter Umständen keinen Sinn mehr, wenn sich Markt- oder technologische Rahmenbedingungen drastisch geändert haben. Unüberwindbare Hindernisse, z. B. wenn relevante Arbeitspakete aus anderen Bereichen nicht geliefert werden, oder eine massive Fehleinschätzung der Aufwände für den aktuellen Sprint können ebenfalls die Weiterführung eines Sprints in Frage stellen.

Oder besser doch nicht abbrechen?

Ein Sprint-Abbruch sollte nur im äußersten Notfall in Betracht gezogen werden. Meistens lassen sich aufkommende Hindernisse auch anders überwinden. Wenn sich beispielsweise  Anforderungen ändern, kann über einen Story-Tausch während des laufenden Sprints nachgedacht werden. Noch nicht begonnene Stories können gegen neue ausgewechselt werden. Solch ein Tausch sollte allerdings immer in Absprache mit dem Team passieren, da sich schließlich Scope und Aufwand für den Sprint ändern. Prinzipiell sollte natürlich auch dieses Vorgehen nicht die Regel sein. Eine andere Möglichkeit wäre, dass das Team die neuen Anforderungen vom Product Owner entsprechend für den nächsten Sprint priorisieren lässt, so dass ein Sprint-Abbruch nicht notwendig ist. Denn ein Abbruch ist mit Schmerzen für das Entwicklungsteam verbunden, dem Verwerfen von getaner Arbeit und dem Verlust von Ressourcen, da sich das Team beim nächsten Sprint Planning neu finden muss.

Wer darf einen Sprint abbrechen?

Auch wenn der Abbruch eines Sprints die absolute Ausnahme sein sollte, führt manchmal kein Weg daran vorbei. Doch wer entscheidet letzten Endes eigentlich über den Abbruch?

Im Scrum Guide steht, dass lediglich der Product Owner diese Entscheidung treffen darf – nicht das Entwicklungsteam und auch nicht der Scrum Master. Doch warum ist das so geregelt? Schließlich kann es auch vorkommen, dass das Team während eines Sprints feststellt, dass es das Sprint-Ziel nicht mehr erreichen kann – und in der Scrum-Theorie wird doch sonst auch stets auf die Selbstorganisation des Teams hingewiesen und dass das Sprint Backlog dem Entwicklungsteam gehört. Warum sollte es dann nicht auch entscheiden können, wann es einen Sprint abbrechen will?

Eigentlich ist die Antwort darauf recht simpel. Das Entwicklungsteam kann die Auswirkungen eines Sprint-Abbruchs oftmals gar nicht abschätzen. Gemeint sind damit die Konsequenzen, die ein Abbruch auf den Kundennutzen und die Wertsteigerung des zu entwickelnden Produktes hat. Ein Sprint enthält nur jene Dinge, die den Kundennutzen steigern. Die Entscheidung, welche Dinge das sind, trifft der Product Owner und nicht das Entwicklungsteam. Durch Priorisierung und Sprintplanung sorgt der Product Owner stets dafür, dass die wichtigsten Anforderungen oben im Backlog stehen – daher ist er auch der einzige, der über den Abbruch eines Sprints entscheiden kann.

In der Praxis kommt es dennoch vor, dass Scrum Master oder Entwicklungsteam den Sprint-Abbruch vorschlagen. Die Betonung liegt hier allerdings auf vorschlagen. Bei einem Sprint-Abbruch handelt es sich um eine weitreichende Konsequenz, die Auswirkungen auf den Fortschritt und die Wertsteigerung des Produkts hat. Aus diesem Grund kann nur eine Person die Verantwortung hierfür übernehmen – der Product Owner. Die Entscheidung für oder gegen einen Abbruch muss er natürlich nicht gänzlich alleine fällen, allerdings sollte er die letzte Instanz sein und sein Einverständnis geben.

Fazit

Ich habe bisher noch nicht viele Sprint-Abbrüche, jedoch schon einige Scope-Änderungen während eines Sprints miterlebt. Letzteres kann ebenfalls dafür sorgen, dass ein Sprint-Ziel obsolet wird. Ob es dann sinnvoll ist, den Sprint abzubrechen oder nicht, muss abgewägt werden. Gerade bei kurzen Sprint-Zyklen sind Abbrüche eher unüblich, da sie nicht nur Ressourcen verbrauchen, sondern auch schmerzhaft für das Team sind. In den meisten Fällen lassen sich geänderte Anforderungen, Hindernisse oder neue Rahmenbedingungen auch anders überwinden, als durch einen Sprint-Abbruch.

Du willst mehr über die Rolle des Product Owner erfahren? Dann lade dir unser kostenloses Whitepaper herunter.

product-owner-whitepaper

    
Über Katharina Lattenkamp

Katharina Lattenkamp vereint die Rollen des Usability Engineers und Product Owners bei der itemis AG. Sie unterstützt Kunden bei der Planung und Durchführung von Usability-Maßnahmen in agilen Softwareentwicklungsprozessen. Ihre Arbeitsschwerpunkte liegen im Bereich Agile Methoden, Usability Testing und Agile UX.