Am Anfang des Sprints werden Ziele definiert. Alle Teammitglieder arbeiten gemeinsam um die definierten Ziele zu erreichen. Sie stimmen sich täglich ab und fragen sich regelmäßig ob sie die Ziele noch erreichen können, bzw. was getan werden kann, damit sie auf jedem Fall erreicht werden. Es gibt Teams die viel Druck vom Management oder von sich selbst bekommen um die Sprint-Ziele immer zu erreichen. Schafft ein gut funktionierendes Scrum-Team IMMER die Sprint-Ziele?
3 Antworten
Grundsätzlich finde ich es schon gut, wenn man Ziele erreicht.
Wenn es allerdings so ist, dass Ziele immer erreicht werden, fühlt sich das für mich so an, dass ggf. nicht ambitioniert genug geplant wurde und man es sich zu leicht gemacht hat. Von daher habe ich kein Problem, wenn man ein Ziel auch mal nicht erreicht. Getreu dem Motto der Jet-Piloten: „Aim high!“
Allerdings sollte es auch nicht so sein, dass Ziele immer verfehlt werden, da die Motivation durch das erreichen gesteckter Ziele definitiv eine positive Auswirkung auf das Selbstvertrauen des Teams, der Teammitglieder und auch das Vertrauen der Organisation in die Leistungsfähigkeit des Teams hat.
Wenn es allerdings so ist, dass Ziele immer erreicht werden, fühlt sich das für mich so an, dass ggf. nicht ambitioniert genug geplant wurde und man es sich zu leicht gemacht hat. Von daher habe ich kein Problem, wenn man ein Ziel auch mal nicht erreicht. Getreu dem Motto der Jet-Piloten: „Aim high!“
Allerdings sollte es auch nicht so sein, dass Ziele immer verfehlt werden, da die Motivation durch das erreichen gesteckter Ziele definitiv eine positive Auswirkung auf das Selbstvertrauen des Teams, der Teammitglieder und auch das Vertrauen der Organisation in die Leistungsfähigkeit des Teams hat.
Ich bin der Meinung, dass die Ziele auch mit einer Herausforderung verbunden sein sollen, die aber auch erreichbar ist. Damit bekommen wir auch ein Erfolgserlebnis am ende des Sprints, wenn die Ziele am Ende erreicht wurden. Das bedeute aber auch, dass es Sprints gibt, in welchen das Ziel nicht erreicht wird. Dies wiederum kann man auch als Chance sehen zu lernen (Warum hat es nicht geklappt?) oder als Anspron für den nächsten Sprint sehen, das Ziel wieder zu erreichen.
Jeff Sutherland vertritt die Meinung, dass erfahrene Teams in 80% der Fälle die Sprintziele erreichen sollten. Oder etwas anders formuliert, sagt er, dass gute Teams in einem von fünf Sprint die Ziele nicht erreichen.
Alos auch ein gut funktionierendes Team schafft es nicht immer ihre Sprint-Ziele zu erfüllen. Das ist auch gut so, denn es bietet uns immer die Chance zu lernen und uns dadurch zu verbessern.
Jeff Sutherland vertritt die Meinung, dass erfahrene Teams in 80% der Fälle die Sprintziele erreichen sollten. Oder etwas anders formuliert, sagt er, dass gute Teams in einem von fünf Sprint die Ziele nicht erreichen.
Alos auch ein gut funktionierendes Team schafft es nicht immer ihre Sprint-Ziele zu erfüllen. Das ist auch gut so, denn es bietet uns immer die Chance zu lernen und uns dadurch zu verbessern.
Wichtig ist für den Erfolg der von mir bisher betreuten Teams gewesen, dass sie gegenüber dem Service Owner und den Stakeholdern verlässlich sind und sich auch entsprechend zu dem Sprintziel committen können. Wurde das Sprint Backlog doch mal früher fertig, dann wurde ein Ticket nach Absprache mit dem Product Owner nachgezogen.
Wichtig ist für mich, dass die Leute in einen Flow kommen und sich gut bei der Sache fühlen und der Kunde sowie Service Owner damit hochzufrieden sind. Um das Vertrauen des Scrum Teams in die Erreichung des Sprint Backlogs zu überprüfen, führe ich am Ende des Planning 1 immer ein Confidence Vote mit dem Team durch, das sich bisher auch positiv auf den Sprint ausgewirkt hat.
Dies geschieht durch das Heben der Hand und Anzeige eines Werts von 0 bis 5 durch Ausstrecken der Finger (0 Finger -> kein Vertrauen / 5 Finger -> volles Vertrauen). Es hat sich bewährt, das Sprint Committment zu akzeptieren, wenn der ermittelte Durchschnittswert größer ist als Drei. Ist der Wert schlechter, sollte die Sprintplanung überarbeitet und über weitere Maßnahmen zur Risikominimierung nachgedacht werden.
War ein Sprint Backlog am Ende des Planning 1 demnach aber zu wenig ambitioniert geplant / das Vertrauen konstant bei 5, haben die Teammitglieder dann noch innerhalb des Planning 1 die Möglichkeit gehabt, ein passendes Product Backlog Item nachzuziehen.