Commitment Product Owner

Stefan Roock schreibt über das Commitment des Product Owners, dass dieser sich ebenfalls auf die Sprint-Planung verpflichtet. Der PO darf – wie das Entwicklungsteam auch – deshalb das Ergebnis der Sprint-Planung nur dann akzeptieren, wenn er es für sinnvoll hält.

Ziele der Sprint Planung

Zunächst ist das Planning ein Instrument, um die kommenden 1-4 Wochen (je nach Länge der Sprints) zu planen. Im Rahmen der Planungssitzung einigen sich Entwicklungsteam und Product Owner auf die zu erreichenden Ziele und die hierfür zu erledigenden Stories. Es ist entscheidend, dass eine Übereinkunft erzielt wird, dass die vereinbarten Ziele und Sprint-Elemente sinnvoll sind und umgesetzt werden können. Nur Planungssitzungen die mit einer Übereinkunft hinsichtlich Umfang, Zielsetzung und Sinnhaftigkeit enden sind zielführend. Plannings, die nur „pro forma“ durchgeführt werden und deren Ergebnisse im Sprint-Verlauf ignoriert werden (Priorität, „ach da kommt was Neues!“, „machen wir doch nicht“) sind nicht hilfreich sondern schädlich.

Probleme bei der Planung von Sprints

Typische Probleme von Product Ownern im Rahmen der (Sprint)Planung sind:

  • Die Planung wurde nicht vorbereitet, das Team sieht die Stories im Planning zum ersten Mal. Unsicherheit erhöht den geschätzten Aufwand. Im Planning die Unsicherheiten zu reduzieren kann zeitaufwändig und nervenaufreibend sein.
  • Trotz Vorbereitung durch Backlog Groomings und Weitergabe von Informationen an das Team kann es vorkommen, dass erst in der Planungssitzung oder erst im Planning 2 Abhängigkeiten aufgedeckt werden, die eine (wirtschaftlich) sinnvolle Planung des Sprints sehr schwer machen.
  • Aus Sicht des Product Owners wird zu viel Aufwand in Grundlage wie Infrastruktur und Entwicklungsumgebung investiert. Das Vorhaben erscheint nicht mehr wirtschaftlich umsetzbar. Der geschätzte Aufwand für die besprochenen Stories ist so hoch, dass eine wirtschaftliche Umsetzung zweifelhaft erscheint. Dies wird jedoch erst im laufenden Projekt erkannt.