Laut Ken Schwaber „besteht der Mindestplan, der zum Starten eines Scrum-Projekts erforderlich ist, aus einer Vision und einem Product Backlog. Die Vision beschreibt, warum das Projekt durchgeführt wird und was der gewünschte Endzustand ist.“
Auch der Product Owner soll eng mit dem Team zusammenarbeiten, um diese Produktvision zu erstellen. Dies ist wünschenswert, da das Team durch die Teilnahme an diesem Prozess ein tieferes Verständnis der Vision haben wird.
Angesichts dessen braucht es in unserer großen Organisation Zeit und mehrere Treffen mit den Stakeholdern, um einen Konsens über die Vision und die Produktausrichtung zu erzielen. Ist es also in Ordnung, einen Sprint 0 ohne auslieferbaren Code zu haben?
Ich glaube, Ihr Problem besteht darin, einen Prozess, der vor der Einleitung Ihrer Sprints stattfindet, in einen Anfangssprint zu verwandeln. Ihre Situation wirft meiner Meinung nach zwei Fragen auf.
1. Ist es die Scrum-Methodik, einen Sprint ohne ein lieferbares Ergebnis zu haben?
Normalerweise nicht.
Scrum beabsichtigt, eine detaillierte Vorabplanung zu vermeiden, und das Konzept, Dinge „erledigt“ zu bekommen, ist ein wichtiger Aspekt. Während Sie kreativ sein können, wenn Sie „erledigt“ definieren, ist das Konzept „Sprint 0“ letztendlich nicht Teil der Scrum-Philosophie, ebenso wenig wie ein Plan, der keine Funktion liefert, die ausgeliefert werden kann.
2. Kann ich Scrum an meine Bedürfnisse anpassen?
Sicher - aber es wäre nicht Scrum.
Allerdings spricht nichts dagegen, Scrum rein, wenn das Ihr Ziel ist, in der von Ihnen beschriebenen Situation nicht umzusetzen. Während das Zitat von Ken Schwaber, das Sie von Ken Schwaber geben, wahr ist: „Der erforderliche Mindestplan zum Starten eines Scrum-Projekts besteht aus einer Vision und einem Product Backlog“, schließt dies nicht die Möglichkeit aus, dass in Ihrer Organisation mehr als das erforderlich ist.
Diese zusätzliche Planung vor Beginn einer Reihe von Sprints muss nicht als "Sprint 0" definiert werden. Wenn Ihr Entwicklungsökosystem aufgrund interner Richtlinien eine Projektplanung erfordert, ist es vollkommen legitim, die Dinge einfach beim Namen zu nennen – bezeichnen Sie dies als einen eigenständigen Prozess außerhalb Ihrer Implementierung der Scrum-Methodik.
Ist es in Ordnung, einen Sprint 0 ohne lieferbaren Code zu haben?
Dem Scrum-Framework treu bleibend, wäre die Antwort NEIN.
Kannst du den Sprint 0 timen? Wenn die Antwort nein lautet, würden Sie gegen zwei wichtige Faktoren des Scrum-Frameworks verstoßen, erstens gegen Timeboxing und zweitens gegen potenziell auslieferbaren Code am Ende jedes Sprints. Wie Sie bereits erwähnt haben, braucht die Organisation Zeit und mehrere Treffen mit den Interessengruppen, um einen Konsens über die Vision und die Produktausrichtung zu erzielen. Daher könnte das Timeboxing dieser Übung wider alle Hoffnung hoffen.
Aus diesem Grund nennt Mike Cohn diesen Teil ein Projekt vor dem Projekt :
Während dieses Projekts vor dem Projekt können die frühen Teammitglieder (vielleicht nur ein zukünftiger Product Owner) darauf hinarbeiten, ein anfängliches Produkt-Backlog zu erstellen, Teammitglieder zu finden oder einzustellen, die technische Umgebung einzurichten und so weiter.
Eines der größten Probleme mit einem Sprint Zero ist, dass es einen Präzedenzfall dafür schafft, dass es bestimmte Sprints oder Sprinttypen gibt, die einzigartige Regeln haben.
Sogar das Konzept von Sprint Zero ist unter den Gründervätern von Agile umstritten, wie Alistair Cockburn feststellte :
Ich habe das schleichende Gefühl, dass jemand wegen seiner Verwendung von Scrum unter Druck gesetzt wurde, als er etwas tat, das zu Beginn keinen offensichtlichen geschäftlichen Wert hatte, und er erfand "Oh, das war Sprint Zero!", um die Bauern mit den Spitzhacken von ihm wegzubekommen Haustür.
... und dann fanden andere, dass das eine großartige Antwort war, und fingen an, es auch zu sagen. ... und dann wurde es Teil der Kultur.
und mit den Worten von Ken Schwaber :
Genau ... Sprint 0 ist zu einem Ausdruck geworden, der missbraucht wurde, um die Planung zu beschreiben, die vor dem ersten Sprint stattfindet ... und da die Planung Artefakte erzeugt, die sich häufig ändern, sollte sie vor dem ersten Sprint minimiert werden und dann bei jedem Sprint auftreten das Sprint-Review/Sprint-Planungsmeeting (Just-in-Time-Planung)
Es gibt oft Debatten zwischen Scrum-Praktizierenden darüber, ob man einen Sprint Zero haben soll oder nicht. Sie können die verschiedenen Argumente umgehen, indem Sie das Sprintziel für den ersten Sprint neu definieren und die Erwartungen an das, was im Sprint Review gezeigt wird, anpassen.
Manchmal scheint das Streben nach einem „Sprint Zero“ wie die Notwendigkeit einer Werkzeugkette oder eines Architektursprints ohne konkrete Ergebnisse. Wenn Sie jedoch tiefer graben, besteht das eigentliche Ziel oft darin, zu vermeiden, dass der erste Sprint in die Geschwindigkeit Ihres Teams gezählt wird. Alle projektbezogenen Arbeiten sollten jedoch als sichtbare Kosten für das Projekt im Product Backlog ausgeführt werden, also füllen Sie Ihren ersten Sprint bitte nicht mit unsichtbarer Arbeit.
Die technisch korrekte Antwort innerhalb des Frameworks besteht darin, sicherzustellen, dass die erforderlichen Architektur-, Toolketten- und anderen Infrastrukturgeschichten in das Product Backlog aufgenommen werden. Das Sprintziel des ersten Sprints könnte beispielsweise so aussehen:
Installieren Sie die für den Start des Projekts erforderliche Entwicklungsinfrastruktur.
Möglicherweise benötigen Sie zu Beginn eines Projekts sogar mehrere solcher Sprints. das ist auch okay. Die in diese ersten Sprints aufgenommenen User Stories werden ausgewählt, um die definierten Sprint-Ziele zu erfüllen.
Eine wörtliche Interpretation des Sprint-Review-Prozesses scheint Nicht-Feature-Storys zu einem No-Go zu machen. Dies ist jedoch nicht wirklich so. Das Prozessziel besteht darin, den Fortschritt (oder das Fehlen davon) für die Stakeholder sichtbar zu machen und einen Wendepunkt innerhalb des Projekts bereitzustellen, um Stakeholder-Feedback zu sammeln. Dies funktioniert im Allgemeinen am besten mit konkreten oder für Benutzer zugänglichen Funktionen, aber alles, was Sie auf visuelle oder ansprechende Weise demonstrieren können, reicht aus.
Beispielsweise könnte der erste Sprint Review Ihres Teams mit Sicherheit entwicklerorientierte Ergebnisse demonstrieren, wie zum Beispiel:
Es ist Sache des Teams, einschließlich des Product Owners und des Scrum Masters, die Stakeholder über die Notwendigkeit dieser Projektvoraussetzungen aufzuklären. Diese Ergebnisse durch den „Sprint Zero“-Mechanismus unter den Teppich zu kehren, ist eine Möglichkeit, die Notwendigkeit zu umgehen, die Organisation zu schulen, aber es betrügt letztendlich Stakeholder und das Team um die vollen Vorteile eines transparenten Prozesses.
Denken Sie daran , dass Scrum von potenziell auslieferbaren Inkrementen (PSI) und nicht von potenziell auslieferbarem Code spricht ! Natürlich können Sie Code versenden, aber Sie können auch andere Dinge versenden. Beispielsweise könnte ein Produktvisionsdokument ein lieferbares Inkrement sein. Sprints mit dem Ziel, Erkenntnisse zu gewinnen, werden oft als Exploration Sprints bezeichnet. Sie sind nicht ungewöhnlich.
Im Allgemeinen besteht die Idee des lieferbaren Inkrements darin, Sie dazu zu bringen, ein klares Ziel für Ihre Iteration zu definieren. Nur so werden Ihre Fortschritte messbar. Sie können Ihren Fortschritt bei der Aufgabe „Verstehen der Problemdomäne“ nicht messen, aber Sie können den Fortschritt bei der Erstellung eines Dokuments messen, das die Produktvision enthält. Denn im letzteren Fall können Sie das Ergebnis diskutieren und herausfinden, ob es akzeptabel ist oder nicht.