Nachträglich Arbeit in den Sprint aufnehmen

Bild: Unsplash / Jason Goldman - Lizenz

In der Theorie ist es ganz einfach: wenn einem Scrum Team während des Sprints die Arbeit ausgeht zieht es neue nach, und zwar die jeweils am höchsten priorisierte Aufgabe im Product Backlog. Das macht erstmal intuitiv Sinn, in der Realität kann die Situation aber deutlich vielschichtiger sein, bis zu dem Punkt an dem sich dieses scheinbar naheliegende Vorgehen als eines erweist das man gerade nicht wählen sollte. Schauen wir uns das Ganze mal näher an.

Um mit dem Naheliegendsten anzufangen: zuerst stellt sich die Frage warum es keine zu erledigende Arbeit mehr im Sprint gibt. Es ist keineswegs immer so, dass bereits alles erledigt wurde - oft ist zwar noch Arbeit da, die aber durch fehlende Zulieferungen oder ausgefallene Systeme nicht beendet werden kann. Statt neue Arbeit nachzuziehen sollte man sich in solchen Situationen zuerst fragen ob die nötigen Zulieferungen und Reparaturen im Sprint nicht auch selbst erledigt werden können.

Selbst wenn alle Aufgaben im ursprünglichen Sprint Backlog erledigt sind müssen nicht zwangsläufig neue gesucht werden. Stattdessen kann es auch sein, dass zu der bereits erledigten Arbeit sinnvolle Ergänzungen möglich sind. Refactorings des Code können durchgeführt werden, Tests können automatisiert werden, Dokumentationen können vereinheitlicht werden, etc. etc. Das jetzt schon zu tun kann verhindern, dass später "Aufräum-Sprints" nötig werden.

Und noch etwas kann man mit der bereits fertigen Arbeit machen wenn im Sprint noch Zeit übrig ist: sie den Anwendern und Stakeholdern vorführen, deren Feedback einholen und das gegebenenfalls noch im selben Sprint nutzen um die Arbeitsergebnisse noch weiter zu verbessern. Dieser Austausch kann in Scrum auch deutlich vor dem Sprint Review stattfinden, schliesslich steht nirgendwo geschrieben, dass die Neuerungen erst da gezeigt werden dürfen.

Aber unterstellen wir, dass all das nicht möglich (oder bereits erledigt) ist und noch immer Kapazität im Sprint übrig ist. Auch dann ist die oberste Aufgabe im Product Backlog nicht automatisch die Beste. Sie sollte auch im verbleibenden Sprint abschliessbar sein. Ist das nicht der Fall besteht das Risiko, dass sich im nächsten Planning die Prioritäten ändern und dass das halbfertige Ergebnis danach so lange auf Halde liegt bis es veraltet ist und die Arbeit umsonst investiert wurde.

Ein weiterer zu berücksichtigender Fall tritt ein, wenn der Backlog-Eintrag für sich genommen noch keine nutzbare Funktionalität erzeugt.¹ Es mag zwar verlockend erscheinen durch eine frühe Umsetzung "Vorarbeit" für das nächste Sprint-Ziel zu erledigen, zum einen besteht aber auch hier das Risiko, dass es im nächsten Planning zum Umpriorisierungen kommt, zum anderen führt eine solche asynchrone Fertigstellung oft zu nicht gut abgestimmten Ergebnissen und zu höheren Integrationsaufwänden.

Um es auch von der positiven Seite zu betrachten - was kann man denn guten Gewissens in einen Sprint nachziehen? Idealerweise Arbeitspakete deren Umsetzung bereits für sich genommen einen Mehrwert erzeugt und die in der noch verbleibenden Zeit des Sprints vollständig umsetzbar sind. Selbst wenn sie nicht die höchste Priorität im Backlög haben sollten stiften sie einen Mehrwert, gleichzeitig können die in den letzten Absätzen genannten Risiken vermieden werden.

Falls sie alle in der verbleibenden Zeit umsetzbar sind können auch mehrere zusammengehörende Backlog-Einträge in den Sprint gezogen werden, die sich dann durch ein "Zusatz-Sprintziel"² verbinden lassen. Gegebenenfalls ist es zu diesem Zweck auch möglich aus einem für die verbleibende Sprintdauer zu grossen Ziel einen Spike, ein Proof of Concept oder ein MVP herauszulösen, das auch allein für sich genommen von Wert ist.

Was ich auch schon erlebt habe ist, dass sich Teams die ihr Sprintziel vorzeitig erreicht haben aus dem Backlog eine "Carte Blanche" ziehen konnten, mit der sie an allem arbeiten konnten wozu sie sonst nicht gekommen sind, vom Abbau technischer Schulden über die Verbesserung der eigenen Entwicklungstools bis hin zum Erlernen neuer Programmiersprachen. Für viele war das ein zusätzlicher Anreiz um ihre Arbeit möglichst schnell und gut zu erledigen.³

Und ganz zuletzt - vielleicht muss man auch gar keine Arbeit nachziehen und kann stattdessen Überstunden abbauen. Auch das passiert in manchen Teams viel zu selten.

¹Dass in Scrum jeder Backlog-Eintrag zwingend potentiell nutzbare Funktionalität erzeugen müsste ist ein Mythos, das trifft nur auf Sprint-Ziele zu.
²Ggf. mit anderem Namen, da es ja eigentlich nur ein Sprintziel geben soll.
³Nur um es klarzustellen: natürlich sollte man auch unabhängig vom Sprint-Status an diesen Themen arbeiten können.