Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03204.jsonl.gz/554

Commitments und Forecast sind Themen die immer wieder zu Diskussionen führen. Zu was verpflichtet sich ein Scrum Team wenn es sich zum Sprint Backlog "committed" und wie verbindlich sind Vorhersagen zu Umfang und Ziel des Sprints? Ich versuche hier mal etwas Klarheit zu schaffen.
Das am häufigsten genannte Missverständnis bezieht sich auf die Product Backlog Items (PBI), welche das Sprint-Backlog definieren und zu dessen Umfang sich das Scrum Team "committed". Was bedeutet dieses "Commitment"? Was bedeutete es, wenn das Scrum Team den Umfang des Sprint-Backlog nicht abarbeiten konnte bis zum Ende des Sprints?
Verbindlichkeit
Lasst uns herausfinden, was mit "Commitment" eigentlich gemeint ist: Eine schnelle Online-Suche ergibt diese beiden Definitionen:
- "Der Zustand oder die Eigenschaft, sich einer Sache oder Tätigkeit zu widmen"
- "Ein Engagement oder eine Verpflichtung, die die Handlungsfreiheit einschränkt".
Diese Definitionen sind in ihrer Bedeutung recht unterschiedlich. Die erste bezieht sich auf die Hingabe, die zweite auf einen zukünftigen Zustand, den wir zu erreichen versprechen oder garantieren.
Historie des Scrum Guides
Commitment und Forecast sind auch im Scrum Guide Themen, die über die Zeit stark angepasst wurden um mehr Klarheit zu schaffen.
2010
[...] Das Team hat sich zu einem Sprint Goal und zu dessen Product Backlog Items verpflichtet. [...]
In dieser ersten Version des Scrum Guide wird darauf verwiesen, dass es eine feste Verpflichtung gibt, dass alle Elemente, die in einen Sprint aufgenommen werden, erledigt werden müssen. Wenn am Ende des Sprints nicht alle ausgewählten Punkte erledigt sind, dann hat es vielleicht ein Problem gegeben, das es wert ist, weiter untersucht zu werden. Haben wir also als Team versagt, da wir nicht alles erreicht haben, was wir versprochen haben?
Ein potenziell interessanter Punkt in diesem Zusammenhang ist die Tatsache, dass wahrscheinlich viele Teams, die heute Scrum anwenden, die ursprüngliche Version von 2010 nie gelesen haben, aber dennoch fest davon überzeugt sind, dass alle ausgewählten Punkte erledigt werden müssen, weil sonst etwas schief gelaufen ist. Wenn dies nicht durch die Lektüre dieser Version entstanden ist, könnte es dann an der Kultur und den Verhaltensweisen liegen, die bereits in der breiteren Organisation vorhanden sind?
Scrum Guide 2011
Glücklicherweise blieb diese Verwendung von Commitment nicht lange bestehen und wurde 2011 aktualisiert.
[...] das Entwicklungsteam prognostiziert die Product Backlog Elemente, die es im Sprint liefern wird [...]
[...] das Entwicklungsteam prognostiziert, was es glaubt, im kommenden Sprint leisten zu können [...]
[...] Commit wird jetzt prognostiziert [...]
Schon früh wurde erkannt, dass es bei der Komplexität und der grossen Menge an Unbekannten schlichtweg nicht möglich ist, alles, was zu tun ist, perfekt zu planen, auch nicht innerhalb der Timebox eines Sprints.
Scrum Guide 2016
In der Version von 2016 wurden die Scrum-Werte eingeführt, und einer dieser Werte ist das Engagement.
In diesem Zusammenhang bedeutet dies (aber nicht nur), dass wir uns verpflichten, professionell zu sein, uns zu Qualität zu verpflichten, uns gegenseitig zu helfen und zu unterstützen, uns zu verpflichten, an schwierigen Problemen zu arbeiten, uns zu unseren Zielen zu verpflichten. Dies berührt beide Bedeutungen des Begriffs Engagement. Sowohl aus der Perspektive des Engagements und der Anstrengung als auch aus der Perspektive des Versprechens, sich auf die Erreichung zukünftiger Ziele zu konzentrieren.
Scrum Guide 2020
Im Jahr 2020 wurden 3 Verpflichtungen hinzugefügt. Somit hat jedes der drei Kernartefakte nun ein entsprechendes Commitment, die alle dazu beitragen, Transparenz in das Artefakt zu bringen, für das sie ein Commitment sind
- Für das Inkrement haben wir nun die Definition von Done
- Für das Product Backlog haben wir das Product Goal
- Für das Sprint Backlog haben wir das Sprint Goal
Die Entwickler halten sich an die Definition of Done, das ist absolut nicht verhandelbar. Das ist eine feste Verpflichtung. Ein Versprechen.
Das Product Goal und das Sprint Goal helfen Scrum-Teams, sich auf den aktuellen Fortschritt in Richtung eines zukünftigen Zustands zu konzentrieren, der der Empirie dient. Ein Scrum Team verpflichtet sich, zu einem bestimmten Zeitpunkt an einem Product Goal zu arbeiten und dieses Product Goal entweder zu erreichen oder aufzugeben, bevor es zum nächsten übergeht.
Das Sprint Goal wird vom gesamten Scrum Team während des Sprint Planning erstellt (wohlgemerkt, vom gesamten Scrum Team und nicht nur vom Product Owner). Die Entwickler verpflichten sich dann, bis zum Ende jedes Sprints mindestens ein nutzbares Inkrement zu erstellen, das dieses einzelne Sprint Goal erreicht. Dies ist ihre Verpflichtung. Sie verpflichten sich nicht dazu, alle Product Backlog Items eines Sprints fertig zu stellen. Je weiter der Sprint fortschreitet und je mehr man über diese Arbeit erfährt, desto mehr entwickelt sich das Sprint Backlog. Es muss ein gewisses Mass an Flexibilität geben, das das Sprint Goal bietet. Der Scrum Guide macht dies sehr deutlich:
[...] das Sprint Goal ist eine Verpflichtung der Entwickler, es bietet Flexibilität in Bezug auf die genaue Arbeit, die nötig ist, um es zu erreichen. [...]
Das Sprint Goal ist das Ergebnis, das wir erreichen wollen.... die Product Backlog Items, die ausgewählt werden, um dieses Sprint Goal zu erreichen, bilden den Output. Scrum-Teams sollten immer danach streben, die Ergebnisse zu maximieren und den Output zu minimieren. Das Sprint Goal ist ihre Verpflichtung, die ausgewählten Elemente sind ihre Prognose.
Zusammenfassung
Man muss sich immer im klaren sein, wozu man sich verpflichten und was stattdessen eine Vorhersage sein muss, da es sich um eine komplexe Produktlieferung handelt.
Die in einen Sprint aufgenommenen Product Backlog Items stellen eher eine Prognose als eine Verpflichtung dar.
Hingegen sollte man sich zu Zielen verpflichten, dazu jederzeit sein Bestes zu geben, seinen Mitmenschen zu helfen, Produkte von höchster Qualität herzustellen und die Definition of Done (DOD) einzuhalten.
Man muss professionell damit umgehen, welche Verpflichtungen man eingehen kann/soll und welche nicht.