Bei einem Daily Stand-Up erkundigte ich mich nach dem Sprint-Fortschritt und bat um eine Einschätzung, ob das aktuelle Sprint-Ziel eingehalten wird. In diesem Rahmen forderte ich die Entwickler mit Nachdruck auf, eine höher priorisierte Story anzufangen, obwohl die Entwickler zuerst eine für sie spannendere jedoch niedriger priorisierte Story anzufangen beabsichtigten. Dies führte zu einem regelrechten Aufschrei. ScrumMaster arbeiten unterstützend, wurde mir an den Kopf geworfen, und ScrumMaster geben dem selbst organisierten Team doch nicht vor, was für Stories sie bearbeiten sollen. War diese Kritik berechtigt?
Natürlich soll ein Team seine Arbeit selbst organisieren. Und in der Regel sind Eingriffe dieser Art nicht notwendig. Doch falsch sind sie nicht! Wie ich bereits früher geschrieben hatte, sind der Selbstorganisation Grenzen gesetzt. Diese Grenzen sind durch das Sprint-Ziel und das Commitment des Teams auf eben dieses gesetzt. Das Team verpflichtet sich, alles notwendige dafür zu tun, das Ziel zu erreichen. Als Gegenleistung obliegt es ihnen, den Umfang der Aufgaben für den Sprint zu bestimmen.
Dass das Sprint-Ziel nicht immer erreicht werden kann, sollte jedem klar sein. Hier liegt einer der Gründe dafür, warum ein Product Owner die Stories für den Sprint priorisiert. Er muss abwägen, welche Story er auf jeden Fall benötigt und auf welche er unter (widrigen) Umständen in diesem Sprint verzichten könnte. Das Resultat dieser Abwägung ist die Anordnung der User-Stories im Sprint-Backlog.
So lange am Ende alle Stories umgesetzt werden, ist mir als ScrumMaster die Reihenfolge der Abarbeitung im Sprint egal. Wenn jedoch, dank der täglichen Stand-Up-Meetings, erkennbar ist, dass das Sprint-Ziel in Gefahr ist und gleichzeitig an weniger wichtigen Stories gearbeitet wird, stößt die Selbstorganisation an ihre Grenzen und der ScrumMaster muss korrigierend eingreifen - auch wenn es den Entwicklern übel aufstößt. Denn letztendlich hängt hiervon die Releaseplanung des Product Owners ab und er muss sich darauf verlassen können, das zu erhalten, was er dringend benötigt und nicht was das Team für spannend hält.
"ScrumMaster arbeiten doch unterstützend." Das bedeutet aber nicht, dass siedem Geschehen passiv folgen müssen sondern aktiv und klar die Grenzen aufzeigen dürfen. Und als verantwortliche für den Prozess haben sie auch ganz klar das Mandat hierfür.