Scrum Day 2026: Scrum-PO in nicht perfekten Situationen

Auf dem Scrum Day 2026 habe ich einen Vortrag über ein paar Praxistipps für Product Owner*innen gehalten. Auf mehrfachen Wunsch habe ich nun hier die wesentlichen Dinge zum Nachlesen zusammengeschrieben. Lasst uns gerne bei LinkedIn darüber diskutieren.

Um was geht es?

Die PO-Accountability (im Folgenden der Einfachheit halber „Rolle“) ist von Scrum sehr mächtig ausgelegt. Der/die PO entscheidet über die Ausprägung des Produkts für den entsprechenden Markt bzw. für die relevanten Stakeholder und damit über den wirtschaftlichen Erfolg des Produkts. Werfen wir hier zunächst einmal einen Blick in den Scrum Guide. In diesem steht unter anderem:

The Product Owner is accountable for maximizing the value of the product

[…]

For Product Owners to succeed, the entire organization must respect their decisions.

[…]

The Product Owner may represent the needs of many stakeholders in the Product Backlog

In der Praxis operiert ein Scrum Team jedoch zumeist in einer klassischen Organisation, welche die Befugnisse des/der PO einschränkt. Falls Du in einer solchen Situation bist, habe ich hier ein paar Tipps, die für Dich hilfreich sein könnten.

Die Ursprünge

Schauen wir uns zunächst einmal die Herausforderungen in der Produktentwicklung an. Nach Allen Ward gibt es hier vier Aspekte:

• Das Wissen
• Die Verantwortung
• Das Feedback
• Die Arbeit

Traditionell werden diese Aspekte in der Organisation mit vier Rollen / Personen abgedeckt: Systemarchitekt*innen haben das Wissen, Projekt- und Line-Management haben die Verantwortung, das Feedback kommt von Vertrieb oder Produktmanagement, die Arbeit machen die Entwickler*innen. Abstimmungen zwischen diesen vier Rollen müssen schnell und mit einem gemeinsamen wirtschaftlichen Ziel geschehen – leider haben diese vier Rollen oft verschiedene Vorgesetzte und Zielsetzungen.

Übergaben und Abstimmungen gelten im Lean Development als die größte aller Verschwendungsarten und so hat Toyota die vier genannten Aspekte in eine einzige Rolle kombiniert, den Chief Engineer (als Rolle im Folgenden nicht gegendert). Dieser hat die wirtschaftliche Verantwortung für das Produkt, nicht nur für das Entwicklungsprojekt. Der Chief Engineer ist Systemarchitekt, Projektleiter, hat lange in Autowerkstätten mit den Kund*innen gearbeitet und ist Mentor der Entwickler*innen. Das heißt konkret, die Abstimmung zwischen Anforderungen und technischer Lösung laufen beim Chief Engineer zusammen und er entscheidet ohne Abstimmung mit dem Management. Das verkürzt die Entwicklungszeiten und optimiert die Wirtschaftlichkeit des Produkts.

Was hat das mit Scrum zu tun? Das Scrum Team handelt wie ein Chief Engineer. Es hat die wirtschaftliche Verantwortung für das Produkt über den gesamten Lebenszyklus. Es legt die Anforderungen fest (bzw. ändert nach Absprache vorgegebene Anforderungen), damit das Produkt zu minimalen Kosten in kürzester Zeit und mit maximaler Qualität den maximalen Kundennutzen stiftet. Dieselbe Lean-Formel wie in der Produktion.

Zaubermittel Backlog

Das Backlog, als zentrales PO-Tool ist mächtiger als man denkt. Der erste Gedanke, dass damit das Team gesteuert werden soll, greift viel zu kurz. Das Backlog ist viel mehr als der Team-Arbeitsvorrat. Es ist die Roadmap für das Produkt und es bietet die Transparenz um ehrlich mit Veränderung umgehen zu können.

Beginnen wir damit, wie ein gutes Backlog aufgebaut sein sollte.

• Zum Backlog sollte eine Definition of Ready vorhanden sein.
• Backlog Items sollten also als „ready“ oder „non-ready“ erkennbar sein.
• Die Größe der “Ready“-Zone oben im Backlog sollte definiert sein (in Schätzpunkten oder in Sprints gerechnet). Ist sie zu groß oder zu klein, muss weniger oder mehr Backlog Refinement gemacht werden.
• Neben dem Backlog sollte einen Meilensteinplan liegen
• Die Backlog Items vor dem nächsten Meilenstein sollten geschätzt sein, auch wenn noch nicht alle davon ready sind.
• Die angenommenen Sprints bis zum nächsten Meilenstein sollten im Backlog eingezeichnet sein. Das dient dem/der PO um ein Gefühl für die Zeitachse zu bekommen. Die Sprint-Umfänge werden natürlich trotzdem von den Developern festgelegt.
• Ein Release-Burnup oder -Burndown-Chart sollte aktuell neben dem Backlog liegen.

Hast Du als PO ein solch schönes, aktuelles, wohlgepflegtes Backlog, bist Du fein raus. Das sehen wir uns im nächsten Abschnitt bei den Herausforderungen an.

Tipps & Tricks

Nebenjobs

Wenn Du noch andere Themen neben Deiner PO-Rolle an der Backe hast, kannst Du über die „Ready Zone“ im Backlog relativ gut messen, ob Du genügend Kapazität für Dein Team hast. Wird diese zu klein, wird das Team irgendwann unklare Dinge „ansaugen“ und viel Verschwendung betreiben. Das sollte Deinen Führungskräften einleuchten. Rechne vor, wie viel Kapazität in einem Sprint steckt, z.B. 6 Menschen mal 2 Wochen, sind 12 Personenwochen, also ein viertel Personenjahr. Das will gut vorbereitet sein, wenn wir diese Entwicklungspower nicht in den Gully umleiten wollen.

Priorisierung

Wenn Du zusammen mit Deinen Stakeholdern nicht vernünftig an der Priorisierung im Backlog arbeiten kannst, weil scheinbar alles gleich wichtig ist, ist es ein guter Ansatz, eine Priorisierung vorzugeben und dann die Stakeholder um Änderungsvorschläge zu bitten. Das funktioniert besser, als auf einem weißen Blatt Papier anzufangen. Je fundierter Dein Vorschlag ist, desto weniger Diskussionen gibt es bei diesem Ansatz. Eine Möglichkeit wäre die WSJF-Methode zu verwenden, eine Beschreibung findest Du z.B. hier bei Sebastian. Oder Du nutzt die Magic Estimation Methode nicht zur Größenschätzung sondern zur Priorisierung. Dann hast Du die Stakeholder von Anfang an involviert.

Neue Wünsche und Änderungen

Mit einem toll gepflegten Backlog musst Du nie mehr „nein“ zu Stakeholdern sagen. Bei jeder neuen Idee und bei jeder Änderung kannst Du mit den Stakeholdern ans Backlog gehen und sagst Dinge wie: „Sehr gute Idee, ich verstehe, dass es wichtig ist. Das könnten wir gleich hier einplanen. Dann wird aber das hier und das hier nicht mehr ins Release kommen. Hast Du das mit den anderen Stakeholdern schon abgestimmt? Oder sollen wir das Release verschieben? Ja, verstehe, dann klär das doch bitte, wir sind da flexibel.“ Mit einem Backlog als transparente Roadmap kannst Du solche Bälle also volley zurückspielen, bevor sie bei Dir im Feld aufsetzen.

Entscheidungshoheit

Nach der Definition solltest Du als PO alles allein entscheiden können, wenn die Stakeholder gerade nicht greifbar sind. Das optimiert das Produktkonzept und spart viel Wartezeit. Vermutlich wird das aber in Deiner Organisation anders gehandhabt. Hier musst Du einen Weg finden, um zu klären, welche Art von Entscheidungen wie getroffen werden sollen. Ein gutes Werkzeug dazu ist Delegation Poker von Jurgen Appelo. Vielleicht kannst Du hier mit Vorgesetzten und Stakeholdern ein Delegation Board bauen.

Was ist mit dem Budget?

Nachdem das Scrum Team die Aufgaben des Chief Engineers übernimmt und Du als PO über die Ausprägung des Produkts bestimmst, sollte auch das Budget in Deiner Hand liegen – nicht nur als Budget für das Entwicklungsprojekt, sondern als Werkzeug, um über den Lebenszyklus des Produkts, also die nächsten 5-20 Jahre den Gewinn zu optimieren. Wieviel davon wann in welche Entwicklung geht, ist Deine Entscheidung. So viel zur Theorie. In der Praxis wirst Du vermutlich nicht diese Freiräume haben, die negativen Folgen, dass Deine Organisation Dich nicht einfach machen lässt, muss sie eben aushalten können. Vermutlich wirst Du Dich daher nur um das Budget für Wareneinsatz und Entwicklungswerkzeuge kümmern, denn die Personen werden normalerweise pauschal pro Sprint budgetiert (z.B. „ein Sprint kostet 40.000 EUR“).

Fazit

Auf dem Scrum Day hatten wir noch weitere Publikumswünsche im Backlog, die jedoch in dem kurzen Vortragsslot nicht mehr behandelt werden konnten und auch eher Scrum Master Themen waren, wie z.B. Umgang mit 30%-Zuordnung ins Scrum Team oder anderen Themen à la „wir machen eigentlich kein Scrum, was sollen wir tun“.

Mit den beschrieben Tipps lassen sich jedoch manche übliche PO-Schmerzen etwas abmildern. Kern für die PO-Arbeit ist ein gut gepflegtes Backlog, mit dem notwendigen Umfeld (Meilensteinplan, DoR, Charts, Prognosen usw.) wird es zur zentralen Stelle, um gemeinsam gute Entscheidungen treffen zu können.