Sprint Zero

Immer mehr Teams arbeiten mit einem “Sprint Zero”. Aber ist das wirklich eine gute Idee?

Ein Sprint Zero wird hauptsächlich dann benötigt, wenn bestimmte Dinge vor dem eigentlichen Projektstart erledigt werden müssen. Vielleicht muss erst noch ein Team zusammengestellt oder Hardware besorgt werden. In manchen Projekten wird sogar ein separater Backlog für diesen Sprint gefordert.

Eines der größten Probleme bei einem Sprint Zero ist, dass dadurch für einen bestimmten Sprint oder eine bestimmte Art von Sprints andere Regeln gelten. Beispielsweise ist es bei einem Sprint Zero nicht mehr das Ziel des Teams, am Ende etwas potentiell Auslieferbares zu bekommen. Wie könnte auch etwas potentiell Auslieferbares entstehen, wenn es doch das Ziel des Sprints ist, ein Team für die Entwicklung des Produktes zusammenzustellen.

Sprint 0 vs. Vorprojekt

Meines Erachtens gehören die meisten Dinge, die als Argument für einen Sprint Zero angesehen werden, eigentlich eher in ein “Projekt-vor-dem-Projekt”. Vor einem Entwicklungsprojekt gibt es oft ein separates Projekt, in dem entschieden wird, ob es überhaupt ein Entwicklungsprojekt geben soll. Bevor also ein Unternehmen mit einem neuen großen Projekt anfängt, sollte immer erst darüber nachgedacht werden, ob dieses Projekt überhaupt durchgeführt werden sollte.

Die Entscheidung für oder wider Sprint Zero kann als eigenständiges Projekt betrachtet werden.

Da Scrum ein guter Rahmen für das Projektmanagement darstellt, kann es auch für das Projekt-vor-dem-Projekt genutzt werden. In diesem Projekt-vor-dem-Projekt können die bereits feststehenden Teammitglieder (oder auch nur der zukünftige Product Owner) einen ersten Product Backlog erstellen, Teammitglieder finden, die technischen Voraussetzungen schaffen etc.

Ich finde es sinnvoll, diese Arbeiten als eigenes Projekt anzusehen, weil ein einziger Sprint dafür oft nicht ausreicht. Wie würde ein Team dann seinen zweiten Sprint nennen, wenn Sprint 0 nicht ausreicht? Sprint 0,5?

An dieser Stelle muss man ein paar Dinge beachten:

• Halten Sie das Projekt-vor-dem-Projekt möglichst einfach. Die meisten Entwicklungsprojekte benötigen sogar gar kein weiteres Projekt vorab.

• Halten Sie sich an die Prinzipien von Scrum. Bei der Durchführung eines Projekts-vor-dem-Projekt wird nichts potentiell Auslieferbares entstehen. Und das ist auch in Ordnung. Aber denken Sie dabei immer daran, warum es ein so zentraler Grundsatz von Scrum ist, am Ende etwas potentiell Auslieferbares zu bekommen. Und das sollten Sie auch bei dem Projekt-vor-dem-Projekt beachten.