Product Owner 101: 9 Gründe für gescheiterte Projekte (Part 2)

Requirements, Change Requests, Scope Creep. Bestimme die Gründe für gescheiterte Projekte und finde Hilfsmittel, die dich als Product Owner unterstützen.

Im ersten Teil hast du bereits einen Überblick über 4 Gründe erhalten, inwiefern Projektplanung und gescheiterte Projekte zusammenhängen können. Der zweite Part knüpft an das Thema an und dreht sich rund um den Product Owner in seiner Position als Scope Manager. Auf welche Stolperfallen du achten solltest, erfährst du anhand der folgenden 3 Punkte.

#5 – „Nein“ ist für dich ein Fremdwort.

Ein anderer Tag, eine andere Firma. Alles könnte so perfekt sein. Die User Stories sind horizontal geschnitten und nach Value priorisiert. Alles läuft rund. Plötzlich stürmt der Chef zur Tür herein: „Der Vorstand“, er atmet scharf ein und fährt fort: „möchte, dass das Datum-Inputfeld durch einen Date Picker ersetzt wird! WIR KÖNNEN SONST NICHT LIVE GEHEN!“ Die Tür klappt wieder zu und ich frage mich: „Wen interessiert denn dieses Eingabefeld?“

„Immer schnappt das Dringende dem Wichtigen die Zeit weg.“ – Hans-Jürgen Quadbeck-Seeger (*1939)

Scope Creep

In Projekten kommt es regelmäßig vor, dass der Projektumfang unkontrolliert ins Unermessliche wächst. Das können neue Features oder die vielen Kleinigkeiten, die im Refinement dazu kommen („War doch klar, dass…“ und „Ach, mir ist gerade eingefallen, dass…“), sein. Der Endtermin bleibt in diesen Fällen gleich. Dieses Szenario wird als Scope Creep bezeichnet. Scope Creeping ist für mich eine zentrale Ursache, die gescheiterte Projekte ankündigen kann. Egal, ob Product Owner, Produktmanager oder Projektleiter, um eine Sache kommst du daher nicht herum: Verteidige dein Product Backlog!

Anfragen mit geringem Mehrwert solltest du entweder nach unten priorisieren oder ganz ablehnen. [1] Es ist wichtiger, alle Stories mit hohem Value, also Mehrwert, abzuarbeiten. Das gilt aber nicht nur für klassisches Projektmanagement, sondern ist auch bei agiler Produktentwicklung dringend notwendig. Hier hilft gute Kommunikation oft weiter: Liefert das gewünschte Feature wirklich einen enormen Mehrwert? Hat es eine große Auswirkung auf den Produkterfolg? Solltest du, dein Team und die Stakeholder sich nicht sicher sein, dann nutzt beispielsweise Impact Mapping, um die verschiedene Optionen zu identifizieren, die auf die Produktvision oder ein bestimmtes Bestreben abzielen.

Impact Mapping

Eine Impact Map lässt sich mit einer Mind Map vergleichen, die um das Warum, Wer, Wie und Was erweitert wurde. Es ist eine Visualisierung von Scope und den entsprechenden Annahmen. Sie stellt einen Zusammenhang zwischen Ziel, Akteuren, erwarteter Auswirkung und den zu erbringenden Leistungen her. [2] Dabei soll sie dazu beitragen, verbreitete Probleme wie Scope Creep, falsche Lösungen, Pet Features, falsche Annahmen und Priorisierung ohne Businesskontext in den Griff zu bekommen. [3]

Impact Map Beispiel, um gescheiterte Projekte vorab vorzubeugen

Die primäre Ebene einer Impact Map ist das Ziel. An zweiter Stelle stehen die Akteure. In den Gesamtzusammenhang fließt auf der dritten Ebene der jeweilige Impact basierend auf Annahmen ein. An letzter und unwichtigster Stelle steht ein Ausschnitt der Deliverables. (Tool: miro)

#6 – Du reagierst unflexibel auf Changes.

Sie existieren: Change Requests mit Mehrwert. Der Vorteil agiler Vorgehensweisen ist, dass auf Veränderungen am Markt schneller reagiert werden kann, indem nicht an der ursprünglichen Planung konsequent festgehalten wird. Änderungsanfragen mit hohem Value sollten in jedem Fall berücksichtigt werden. Das bedeutet im Umkehrschluss aber auch, dass andere Tasks entfallen. In meinen Augen ist es die Aufgabe des Product Owners,

in seiner Funktion als Scope Manager nicht nur Scope Creep zu reduzieren,
sondern auch die richtigen high-value Features zu erkennen und wertvolle Änderungswünsche voranzutreiben.

#7 – Wie waren noch gleich die Anforderungen?

Ein neuer Sprint beginnt und dein Team stürzt sich motiviert auf die neusten high-value Stories. Ein paar Tage vergehen und nichts wurde so richtig „fertig“. Ihr schiebt euch die Aufgaben hin und her: Ticket-Ping-Pong. In euren sporadischen Meetings kristallisiert sich heraus, dass niemand so wirklich weiß, was erledigt werden soll. Woran liegt das?

Die Anforderungen sind unklar

Eine User Story ist kein Item auf einem Einkaufszettel. Sie ist ein Versprechen für zukünftige Kommunikation zwischen Product Owner und Development Team. Deine priorisierten Stories im Product Backlog sind im besten Fall auch die Features mit dem höchsten Benefit. Je wertvoller eine User Story, desto weiter oben sollte sie auf deiner Liste stehen. Und je weiter oben eine Story im Product Backlog steht, desto vorbereiteter sollte sie sein. Im regelmäßigen Refinement solltest du prüfen, dass deine priorisierten Stories einfach, verständlich und auf dem aktuellsten Stand sind. Sind sie es nicht oder haben sich im Produktentwicklungsprozess Änderungen ergeben, musst du deine Story anpassen.

Doch damit ist es nicht genug. Jeder im Team muss auch verstehen, worauf die Story abzielt. Was ist das Ziel der Story? Dies erreichst du mit guter, offener, regelmäßiger Kommunikation. Spätestens im nächsten Planning solltest du die Stories des nächsten Sprints durchsprechen und offene Fragen klären. Entstehen Fragen nutze die Gelegenheit, um die Story noch einmal für alle verständlich anzupassen.

Takeaways

Es ist in Ordnung und notwendig, Featurewünsche abzulehnen. Verteidige dein Product Backlog!
Beobachte Veränderungen am Markt und reagiere flexibel auf high-value Änderungswünsche!
Für jedes eingeschobene Feature muss ein anderes entfallen oder entsprechend vereinfacht oder verringert werden.
Stelle sicher, dass Anforderungen, User Stories oder Tasks sorgfältig refined, eindeutig und klar kommuniziert sind.

Hast du ähnliche Erfahrungen gemacht? Teile deine Erlebnisse in den Kommentaren!

Noch nicht genug?

Der Beitrag verdeutlicht, dass neben einem gut gepflegten Product Backlog die Kommunikation eine wichtige Rolle spielt. Welche Gründe für gescheiterte Projekte sich um mangelnde Kommunikation drehen erfährt du in Part 3!

Entdecke darüber hinaus unser vielfältiges Schulungsangebot und erfahre mehr über Anforderungen, Impact Mapping & Co.