Darf der Scrum Mas­ter For­de­run­gen stellen?

Bei einem Dai­ly Stand-Up erkun­dig­te ich mich nach dem Sprint-Fort­schritt und bat um eine Ein­schät­zung, ob das aktu­el­le Sprint-Ziel ein­ge­hal­ten wird. In die­sem Rah­men for­der­te ich die Ent­wick­ler mit Nach­druck auf, eine höher prio­ri­sier­te Sto­ry anzu­fan­gen, obwohl die Ent­wick­ler zuerst eine für sie span­nen­de­re, jedoch nied­ri­ger prio­ri­sier­te Sto­ry anzu­fan­gen beab­sich­tig­ten. Dies führ­te zu einem regel­rech­ten Auf­schrei. Scrum­Mas­ter arbei­ten unter­stüt­zend, wur­de mir an den Kopf gewor­fen, und Scrum­Mas­ter geben dem selbst orga­ni­sier­ten Team doch nicht vor, was für Sto­ries sie bear­bei­ten sol­len. War die­se Kri­tik berechtigt?

Natür­lich soll ein Team sei­ne Arbeit selbst orga­ni­sie­ren. Und in der Regel sind Ein­grif­fe die­ser Art nicht not­wen­dig. Doch falsch sind sie nicht! Wie ich bereits frü­her geschrie­ben hat­te, sind der Selbst­or­ga­ni­sa­ti­on Gren­zen gesetzt. Die­se Gren­zen sind durch das Sprint-Ziel und das Com­mit­ment des Teams auf eben die­ses gesetzt. Das Team ver­pflich­tet sich, alles Not­wen­di­ge dafür zu tun, das Ziel zu errei­chen. Als Gegen­leis­tung obliegt es ihnen, den Umfang der Auf­ga­ben für den Sprint zu bestimmen.

Dass das Sprint-Ziel nicht immer erreicht wer­den kann, soll­te jedem klar sein. Hier liegt einer der Grün­de dafür, war­um ein Pro­duct Owner die Sto­ries für den Sprint prio­ri­siert. Er muss abwä­gen, wel­che Sto­ry er auf jeden Fall benö­tigt und auf wel­che er unter (wid­ri­gen) Umstän­den in die­sem Sprint ver­zich­ten könn­te. Das Resul­tat die­ser Abwä­gung ist die Anord­nung der User-Sto­ries im Sprint-Backlog.

Solan­ge am Ende alle Sto­ries umge­setzt wer­den, ist mir als Scrum­Mas­ter die Rei­hen­fol­ge der Abar­bei­tung im Sprint egal. Wenn jedoch, dank der täg­li­chen Stand-Up-Mee­tings, erkenn­bar ist, dass das Sprint-Ziel in Gefahr ist und gleich­zei­tig an weni­ger wich­ti­gen Sto­ries gear­bei­tet wird, stößt die Selbst­or­ga­ni­sa­ti­on an ihre Gren­zen und der Scrum­Mas­ter muss kor­ri­gie­rend ein­grei­fen – auch wenn es den Ent­wick­lern übel auf­stößt. Denn letzt­end­lich hängt hier­von die Release­pla­nung des Pro­duct Owners ab und er muss sich dar­auf ver­las­sen kön­nen, das zu erhal­ten, was er drin­gend benö­tigt und nicht was das Team für span­nend hält.

„Scrum­Mas­ter arbei­ten doch unter­stüt­zend.“ Das bedeu­tet aber nicht, dass sie dem Gesche­hen pas­siv fol­gen müs­sen, son­dern aktiv und klar die Gren­zen auf­zei­gen dür­fen. Und als Ver­ant­wort­li­che für den Pro­zess haben sie auch ganz klar das Man­dat hierfür.