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.

Mögliche Lösungsansätze:

• Es hilft, sich im Vorfeld (auch vor dem eigentlichen Projektstart) mit dem Team abzustimmen. Ist das Team grundsätzlich in der Lage mit den gegebenen Mitteln das gewünschte Ergebnis zu liefern (Erfahrung, Leistungsfähigkeit) oder gibt es eine große Menge an Risiken die bereits im Vorfeld erkannt werden (Technologie, fehlendes Know-how, schwieriges Umfeld)? Gerade die Einschätzung der Leistungsfähigkeitveines Teams gelingt besser, wenn dieses stabil ist und Product Owner und Team schon längere Zeit zusammen arbeiten.
• Auftretende Probleme im Sprintverlauf sind in Retrospektiven aufzugreifen und Lösungen zu diskutieren. Stefan empfiehlt, keinen Sprint durchzuführen, wenn der Product Owner zu viele Zweifel hat um sich auf ein Planungsergebnis zu committen. Dem muss ich aus eigenen Erfahrungen zustimmen: Statt einem unstrukturierten Sprint ohne wirklich sinnvollem Ziel sollten Product Owner und Team die Gründe ermitteln, warum die Planung nicht erfolgreich durchgeführt werden konnte und gemeinsam Lösungen erarbeiten.
• Die immer wieder aufkommenden Diskussionen um Investitionen in grundlegende Infrastruktur, Architektur und Softwarequalität kann man mit der Reservierung eines Teil des Umsetzungskapazität begegnen, die im Rahmen der Zwischenrelease- / PSI-Planung ausgehandelt wird.

Herausforderung Product Owner Rolle

Zu den Problemen, die in der Rolle des Product Owners begründet sind gehören:

• Der Product Owner ist gar kein echter Product Owner sondern lediglich ein Stellvertreter, der keine echte Entscheidungsbefugnisse hat, vgl. auch die bereits geäußerte Kritik hinsichtlich Business Value und Product Owner:

• Der Product Owner ist nicht in der Lage seine Entscheidungen aus einer wirtschaftlich Perspektive heraus zu fällen. Oft ist dies der Fall, wenn der Product Owner ursprünglich aus der Technik kommt, eher Auftragsarbeiten gewöhnt ist und mehr seinem Bauchgefühl als einem wirtschaftlichen Modell folgt.
• Jeder Product Owner sollte in der Lage sein die Business Value (hergeleitet aus Grenznutzen, Grenzkosten und die Kosten einer Verzögerung) für seine Epics/Feature zu erläutern. Kann er dies nicht, so ist seine Priorisierung entweder eine Bauchentscheidung oder die Entscheidung eines anderen und er nur ausführendes Organ (und damit kein echter PO im klassischem Scrum-Sinn).
• Die Überlastung des Product Owners ist ein weiteres Problem, das in vielen Scrum Teams dafür sorgt, dass die Planung von Sprints und PSIs nicht optimal erfolgt. Die Überlastung wird fast automatische hervorgerufen, wenn der Product Owner seine Rolle voll ausfüllen möchte: Er soll gleichzeitig bei allen Stakeholdern, im Markt, in der Trägerorganisation und im Team aktiv sein. Märkte analysieren, Managementunterstützung sichern, organisatorische Abhängigkeiten klären, Kundengespräche führen, Business Case aufstellen und aktualisieren und die ganzen Aufgaben die nach innen in das Team anfallen (Releaseplanung, Features/Epics/Themes, Stories, Ansprechpartner). Hier hilft nur den Product Owner zu entlasten, einiges kann hierbei auch das Umsetzungsteam übernehmen.