Scrum und der Sprintabbruch bei synchronisierten Sprints

Heute gab es direkt zwei Situationen mit AHA-Effekt und ich möchte gerne das erste Ereignis ansprechen, dass diesem Eintrag auch den Titel gegeben hat – der drohende Sprintabbruch!

Zur Vorgeschichte: Im Sprint-Planning haben sich Team 1 und Team 2 darauf comitted, eine Komponene von Team 3 zu integrieren, damit die eigenen Komponenten sicher miteinander kommunizieren können. Laut diverser Aussagen anderer Mitarbeiter und der Architektur gingen Entwickler und POs davon aus, dass die Komponente von Team 3 fertig und verfügbar sei.Als man sich dann erkundigte, wie die Komponente zu integrieren sei, stellte sich heraus, dass diese noch gar nicht deployfähig ist und dies noch mindestens einen, wenn nicht zwei Sprints dauert. Anschliessend haben Team 1 und Team 2 sich dann beraten, wie sie damit umgehen sollen. Ein Sprintabbruch kam durch die Synchronisation mit den anderen Teams im Unternehmen nicht in Frage und einfach Scheitern lassen wollte man die Userstories dann auch nicht einfach.Nach Diskussion mit den POs und dem ScrumMaster kam man dann überein, diese Userstories wieder zurück ins Backlog zu geben und sich dafür auf die Stories aus dem Themenspeicher zu comitten. Die Gründe dafür wurden als Impediments an das SoS (Scrum of Scrums) kommuniziert und von dort bis ins Management weitergegeben. Letztendlich wurden die Teams für den überlegten, produktiven und konstruktiven Umgang mit der Situation gelobt und die Teams können sich jetzt vollkommen unbelastet an die Arbeit an den anderen Userstories machen. In den kommenden Sprints wird dann auch die zurückgestellte Userstorywieder Thema werden, aber dann ist allen klar, was die Vorbedingung ist, bevor man sich auf diese Story comitten kann!

Veröffentlicht in Scrum

Schreibe einen Kommentar