Das Sprint-Ziel ist seit 2002 Bestandteil von Scrum. Trotzdem verwenden Scrum Teams es nur selten, wie eine Umfrage in meinem fortgeschrittenen Professional Scrum Master Training zeigte.
Was ist der Grund dafür?
Selbst nach 10 Jahren kursieren immer noch viele Mythen um Sprint-Ziele. Die weite Verbreitung dieser Mythen könnte auch der Grund sein, warum dein Scrum Team noch damit kämpft, sich Sprint-Ziele zu setzen. Wenn du erfahren willst, welche Mythen über Sprint-Ziele kursieren und wie du sie widerlegen kannst, dann lies weiter.
Mythos #1: Das Sprint-Ziel ist optional in Scrum
Obgleich im Scrum Guide von 2017 das Sprint-Ziel 27-mal erwähnt wurde, erachteten viele Scrum Teams die Verwendung als optional.
Spätestens seit der Scrum-Guide-Version von 2020 sollte dieser Mythos nun überholt sein. Die neueste Version des Scrum Guides beschreibt das Sprint-Ziel unmissverständlich als einen obligatorischen Teil des Sprint Backlogs. Dies wird auch noch einmal unterstrichen, da das Sprint-Ziel jetzt das Commitment für das Sprint-Backlog darstellt.
Scrum Teams verpflichten sich, sich auf die Erreichung des Sprint-Ziels zu fokussieren.
Mythos #2: Es kann in einem Sprint mehrere Sprint-Ziele geben
Wenn dem so wäre, würde es den Zweck des Sprint-Ziels ad absurdum führen.
Der Zweck des Sprint-Ziels besteht ja gerade darin, dem Scrum Team bei schwierigen Entscheidungen einen Anhaltspunkt zu geben. Muss sich etwa am Ende des Sprints das Team entscheiden, ob sie den Test für einen Product-Backlog-Eintrag abschließen sollten oder ob sie doch eher die Refaktorisierung einer unübersichtlichen Codestelle abschließen sollten, dann kann ihnen das Sprint-Ziel in dieser Situation die Richtung weisen, die Sachen abzuschließen, die für die Erreichung des Sprint-Ziels wesentlich sind.
Nur EIN Sprint-Ziel kann als Kompass fungieren und den Entwicklern bei ihrer täglichen Arbeit die Richtung weisen.
Mythos #3: Alle Einträge des Sprint Backlogs müssen auf das Sprint-Ziel ausgerichtet sein
Das wäre wünschenswert, ist allerdings in der Produktentwicklung unrealistisch.
Iterative und inkrementelle Produktentwicklung zeichnet sich eben dadurch aus, dass wir stets Feedback von Anwendern bekommen, ob die Features des Produkts wie erhofft funktionieren. Dieses Feedback ist nur möglich, wenn sich das Produkt bereits im Live-Betrieb befindet. Live-Betrieb bedeutet allerdings auch, dass es zu Problemen kommen kann. Kritische Probleme müssen häufig unmittelbar behoben werden. Dies ist eine Quelle von Arbeit, die im Sprint Backlog transparent gemacht werden sollte, aber nicht direkt auf das Sprint-Ziel einzahlt.
Auch wenn es noch andere Arbeiten geben kann, die das Scrum Team im Sprint erledigt, hilft das Sprint-Ziel dem Scrum Team, den Zweck des Sprints, „warum dieser Sprint für die Stakeholder wertvoll ist“, nicht aus den Augen zu verlieren.
Mythos #4: Das Sprint-Ziel muss am Anfang des Sprint Plannings definiert werden
Im Sprint Planning muss das Thema „Warum ist dieser Sprint wertvoll?“ behandelt werden.
Achtung: Der Scrum Guide spricht hier von Themen und nicht von Schritten.
Das bedeutet, die folgenden drei Themen müssen nicht zwingend in dieser Reihenfolge vom Scrum Team erarbeitet werden.
- Thema eins: Warum ist dieser Sprint wertvoll?
- Thema zwei: Was kann in diesem Sprint abgeschlossen (Done) werden?
- Thema drei: Wie wird die ausgewählte Arbeit erledigt?
Ob sich das Team dem Thema mehrfach widmet oder die Reihenfolge ändert, spielt nur eine untergeordnete Rolle, wichtig ist:
Am Ende der Sprint Planung muss ein Sprint-Ziel finalisiert worden sein.
Mythos #5: Sprint-Ziele dürfen nicht im Unternehmen transparent gemacht werden
Der Sprint Backlog ist ein Plan von und für die Entwickler im Scrum Team.
Was aber nicht bedeutet, dass er nur für die Entwickler sichtbar sein sollte. Laut dem Scrum Guide sollte sowohl der Entwicklungsprozess und die anfallende Arbeit für diejenigen sichtbar sein, die die Arbeit ausführen, als auch für diejenigen, die die Arbeit empfangen. Deshalb kann es hilfreich sein, das Sprint-Ziel nach dem Sprint Planning mit den Stakeholdern des Produkts zu teilen.
Ein für alle sichtbares Sprint-Ziel schafft nicht nur Transparenz, sondern lädt auch zur Zusammenarbeit ein.
Mythos #6: Sprint-Ziele dürfen keine Einträge im Product Backlog sein
Was können alles Elemente des Product Backlogs sein?
User Stories, Bugs, Ideen, Spezifikationen, Hypothesen oder ein Produkt-Ziel. Kurzum: einfach alle Dinge, die zur Produktverbesserung vom Scrum Team in der Zukunft gemacht werden können. Warum nicht auch Sprint-Ziele?
Zukünftige Sprint-Ziele können sehr wohl als Einträge im Product Backlog festgehalten werden. Im Sprint Planning können sie dann vom Scrum Team zu einem Plan verfeinert werden, welcher beschreibt, wie das Scrum Team dieses Ziel erreichen will. Wir sollten nicht vergessen, dass das Product Backlog Refinement auch im Sprint Planning stattfindet.
Das Scrum Rahmenwerk setzt hier keine Grenzen und beschreibt die Elemente des Product Backlogs schlicht als Product-Backlog-Einträge und das Hinzufügen von Details, Reihenfolge und Größe als kontinuierliche Aktivität.
Mythos #7: Die Entwickler committen sich auf das Sprint Backlog
So lautet der wohl mit Abstand hartnäckigste Mythos!
Dieser zeigt auch, wie gut agiles Arbeiten im Unternehmen oder Scrum Team verstanden wurde. Verpflichten sich Scrum Teams dazu, im Sprint einen festen Umfang zu liefern, haben sie noch nicht die Realität von Produktentwicklung akzeptiert: In der Produktentwicklung ist nur eines gewiss: die Ungewissheit. Diese Ungewissheit hört nicht magischerweise auf, nur weil wir jetzt in Sprints arbeiten. Um diese Tatsache hervorzuheben, dass sich im Sprint die Arbeit, die getan werden muss, um das Ziel zu erreichen, noch ändern kann, schreibt der Scrum Guide: „Obwohl das Sprint-Ziel ein Commitment der Developer:innen ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen.“
Scrum Teams committen sich auf das Sprint-Ziel und nicht auf das Sprint Backlog!
Welchen Mythos habe ich vergessen? Schreibe ihn bitte in die Kommentare!