Entscheiden, was zuerst kommt, und was gar nicht
Die schwerste Arbeit dieser Rolle ist nicht das Sammeln von Anforderungen, sondern das begründete Weglassen von Dingen, die jemand sich gewünscht hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ohne echte Entscheidungsbefugnis wird aus der Rolle eine Weiterleitung
In vielen Häusern gibt es eine Person mit dem Titel Product Owner, deren Priorisierung anschließend in einem Gremium bestätigt wird. Das Ergebnis ist eine Rolle, die Wünsche einsammelt, in Tickets übersetzt und weiterreicht. Erkennbar ist das an einer einfachen Frage: Wer darf entscheiden, dass eine gewünschte Funktion nicht gebaut wird. Fällt die Antwort auf jemand anderen, ist die Rolle nicht besetzt, sondern benannt.
Der zweite Bruch entsteht durch Zuruf. Ein wichtiger Kunde ruft an, eine Führungskraft geht direkt ins Team, und beides landet im laufenden Sprint. Ohne ein Produktziel, gegen das sich eine Änderung abwägen lässt, ist jede dieser Unterbrechungen gleich teuer, weil nichts wichtiger ist als etwas anderes. Mit Ziel wird daraus eine Abwägung, die du sichtbar selbst triffst.
Der dritte Bruch ist zeitlich. Ein Product Owner, der die Rolle neben einer vollen Fachaufgabe trägt, ist im entscheidenden Moment nicht erreichbar. Dann entscheidet das Team selbst, was gemeint war, und das ist keine Anmaßung, sondern Notwehr. Die Folge merkt man erst im Review, wenn etwas Funktionierendes gezeigt wird, das niemand so wollte.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet, wer setzt um, und wo die Rolle im Alltag kippt
Die Zuordnung stammt aus dem Scrum Guide, die Stolperfallen aus Teams, in denen eine Entscheidung bei jemandem lag, der sie nicht treffen durfte. Fast alle Konflikte dieser Rolle lassen sich auf eine dieser fünf Zeilen zurückführen.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Das Produktziel und was es ausschließt | Der Product Owner, in Abstimmung mit den Interessengruppen | Das ganze Team, über mehrere Sprints hinweg | Statt eines Ziels gibt es eine Liste von Funktionen, und dann lässt sich keine einzige Anfrage begründet ablehnen. |
| Eine dringende Anfrage im laufenden Sprint | Der Product Owner, im Abgleich mit dem Sprintziel | Die Developers, die dafür etwas anderes zurückstellen | Die Zusage wird direkt im Team platziert, und der Product Owner erfährt im Review, dass etwas anderes gebaut wurde. |
| Wie viel Arbeit in einen Sprint passt | Die Developers, niemand sonst | Die Developers, entlang des Sprintziels | Der Product Owner verhandelt die Menge, weil ein Termin nach außen zugesagt wurde, und macht aus einer Einschätzung eine Verpflichtung. |
| Umbauten und Sicherheitsarbeit ohne sichtbaren Nutzen | Der Product Owner, auf Basis der Einschätzung der Developers | Die Developers, verteilt über mehrere Sprints | Die Arbeit wird immer wieder verschoben, bis sie als Ausfall oder Sicherheitsvorfall zurückkommt und dann alles andere verdrängt. |
| Wann etwas als fertig gilt | Das Scrum Team gemeinsam, im Rahmen der Vorgaben der Organisation | Die Developers bei jedem einzelnen Eintrag | Der Product Owner nimmt im Einzelfall etwas ab, das die vereinbarte Definition nicht erfüllt, und danach gilt sie für niemanden mehr. |
Das Produktziel und was es ausschließt
- Wer entscheidet
- Der Product Owner, in Abstimmung mit den Interessengruppen
- Wer setzt um
- Das ganze Team, über mehrere Sprints hinweg
- Stolperfalle
- Statt eines Ziels gibt es eine Liste von Funktionen, und dann lässt sich keine einzige Anfrage begründet ablehnen.
Eine dringende Anfrage im laufenden Sprint
- Wer entscheidet
- Der Product Owner, im Abgleich mit dem Sprintziel
- Wer setzt um
- Die Developers, die dafür etwas anderes zurückstellen
- Stolperfalle
- Die Zusage wird direkt im Team platziert, und der Product Owner erfährt im Review, dass etwas anderes gebaut wurde.
Wie viel Arbeit in einen Sprint passt
- Wer entscheidet
- Die Developers, niemand sonst
- Wer setzt um
- Die Developers, entlang des Sprintziels
- Stolperfalle
- Der Product Owner verhandelt die Menge, weil ein Termin nach außen zugesagt wurde, und macht aus einer Einschätzung eine Verpflichtung.
Umbauten und Sicherheitsarbeit ohne sichtbaren Nutzen
- Wer entscheidet
- Der Product Owner, auf Basis der Einschätzung der Developers
- Wer setzt um
- Die Developers, verteilt über mehrere Sprints
- Stolperfalle
- Die Arbeit wird immer wieder verschoben, bis sie als Ausfall oder Sicherheitsvorfall zurückkommt und dann alles andere verdrängt.
Wann etwas als fertig gilt
- Wer entscheidet
- Das Scrum Team gemeinsam, im Rahmen der Vorgaben der Organisation
- Wer setzt um
- Die Developers bei jedem einzelnen Eintrag
- Stolperfalle
- Der Product Owner nimmt im Einzelfall etwas ab, das die vereinbarte Definition nicht erfüllt, und danach gilt sie für niemanden mehr.
Fünf Entscheidungen, die ausschließlich beim Product Owner liegen
- 01 Was überhaupt in das Product Backlog aufgenommen wird.
- 02 In welcher Reihenfolge die Einträge bearbeitet werden.
- 03 Welches Produktziel das Team über mehrere Sprints verfolgt.
- 04 Ob eine Änderung wichtiger ist als das laufende Sprintziel.
- 05 Ob ein Sprint vorzeitig abgebrochen wird, weil das Ziel hinfällig ist.
Was die Rolle stark macht
Wirkung entsteht hier nicht durch Nähe zum Team, sondern durch begründete Entscheidungen, die Bestand haben. Dafür braucht es ein Ziel, eine nachvollziehbare Reihenfolge und die Bereitschaft, das Weglassen zu erklären.
Ein Produktziel formulieren, das etwas ausschließt
Ein Ziel, unter das jede denkbare Funktion passt, ist keines. Beschreib den Zustand, den ihr in den nächsten Monaten erreichen wollt, und benenne dazu, was ihr dafür bewusst nicht angeht. Erst das macht spätere Absagen begründbar.
Nach Wert ordnen, nicht nach Lautstärke
Vergleiche Einträge nach erwartetem Nutzen, Aufwand, Risiko und danach, was ihr durch die Umsetzung lernt. Wenn du die Reihenfolge nicht in zwei Sätzen begründen kannst, hast du sie nicht entschieden, sondern übernommen.
Groß schneiden, aber lieferbar
Ein Eintrag sollte einen Nutzen erzeugen, der sich beschreiben lässt, und trotzdem in einen Sprint passen. Die häufigste Ursache für halbfertige Sprints ist ein Zuschnitt entlang technischer Schichten statt entlang eines Ergebnisses, das jemand verwenden kann.
Technische Arbeit ohne sichtbaren Nutzen einplanen
Umbauten, Abhängigkeitspflege und Sicherheitsarbeit haben keinen Fürsprecher unter den Fachbereichen. Wenn du sie nicht regelmäßig selbst einplanst, kommen sie später als Störung zurück, und dann zu einem Zeitpunkt, den niemand gewählt hat.
Nutzen an einer Messgröße festmachen
Leg vor der Umsetzung fest, woran ihr erkennen wollt, ob die Entscheidung richtig war, und sieh danach nach. Ohne diese Schleife wird jede Priorisierung zur Meinung, und Meinungen setzen sich nach Hierarchie durch.
Erreichbar sein, wenn eine Frage aufkommt
Die teuersten Missverständnisse entstehen in den Stunden, in denen niemand fragen kann. Vereinbare feste Zeiten für Rückfragen und für gemeinsames Zuschneiden, statt darauf zu vertrauen, dass alles im Planning geklärt wurde.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Grenze zum Scrum Master, sauber gezogen
Beide Rollen sind Verantwortlichkeiten in demselben Team, und sie unterscheiden sich nicht durch Seniorität, sondern durch den Gegenstand. Der Product Owner verantwortet, dass das Team an den richtigen Dingen arbeitet, also Inhalt, Reihenfolge und Nutzen. Der Scrum Master verantwortet, dass das Team wirksam arbeiten kann, also Zusammenarbeit, Hindernisse und das Verständnis des Rahmenwerks. Der eine schaut nach außen auf Markt, Kundschaft und Interessengruppen, der andere nach innen und auf die Organisation drumherum.
Praktisch merkst du den Unterschied an der Frage, wer bei einem Problem zuständig ist. Wird immer wieder das Falsche gebaut, ist das eine Frage der Reihenfolge, der Zuschnitte und der Klarheit des Ziels, also deine. Wird das Richtige gebaut, aber es dauert, weil Abnahmen liegen bleiben, weil Leute in drei Vorhaben stecken oder weil die Zusammenarbeit hakt, ist das die Baustelle des Scrum Masters. Die zweite Baustelle kannst du nicht mit besseren Tickets lösen, und die erste löst kein noch so gutes Format.
Beide Rollen in einer Person zu vereinen ist der Fall, in dem es regelmäßig schiefgeht. Dann verhandelt jemand mit sich selbst über den Inhalt des Sprints, und das Team hat niemanden mehr, der auf seiner Seite Grenzen zieht. In kleinen Häusern wird das trotzdem gemacht. Wenn es sein muss, dann mit ausgesprochener Rollentrennung im Termin und mit jemandem außerhalb des Teams, an den sich das Team wenden kann.
Was der Scrum Guide sagt, und was Stellenanzeigen daraus machen
Der Guide beschreibt den Product Owner als eine Person, nicht als Ausschuss. Er verantwortet die Maximierung des Werts, der aus der Arbeit des Teams entsteht, und das Product Backlog Management: das Entwickeln und ausdrückliche Kommunizieren des Produktziels, das Erstellen und Ordnen der Einträge und das Sicherstellen, dass sie verständlich sind. Er darf Teile davon delegieren, bleibt aber rechenschaftspflichtig. Damit die Rolle funktioniert, muss die ganze Organisation seine Entscheidungen respektieren, und genau daran hängt alles Weitere.
In Stellenanzeigen steht häufig etwas anderes. Dort werden Terminverantwortung, Steuerung des Teams, Berichtswesen und manchmal auch Personalverantwortung erwartet. Wenn du dich bewirbst, ist die entscheidende Frage im Gespräch daher nicht, welche Werkzeuge im Einsatz sind, sondern: Wer darf entscheiden, dass etwas nicht gebaut wird, und wer sagt Termine nach außen zu. Aus der Antwort erkennst du, ob du eine Produktverantwortung oder eine Projektsteuerung mit anderem Namen übernimmst.
Die dritte übliche Verwechslung betrifft das Produktmanagement. Im Rahmenwerk gibt es keine Rolle Product Manager. In der Praxis wird der Begriff für die Markt- und Geschäftsseite verwendet, also Zielgruppen, Preisgestaltung, Portfolio und mehrjährige Ausrichtung, während der Product Owner näher am Team arbeitet. In kleineren Häusern ist beides dieselbe Person, in größeren sind es zwei, und dann muss geklärt sein, wer die Reihenfolge im Backlog letztlich verantwortet, sonst hat das Team zwei Auftraggeber.
Der Weg in die Rolle, und was die Zertifikate belegen
Es gibt drei übliche Herkünfte, jede mit einer eigenen Lücke. Aus dem Fachbereich bringst du mit, wofür das Produkt überhaupt da ist, und musst lernen, in lieferbaren Schritten zu denken statt in Endzuständen. Aus der Analyse oder dem Anforderungsmanagement kannst du sauber beschreiben und musst lernen, Entscheidungen zu treffen, statt Anforderungen vollständig zu erheben. Aus der Entwicklung kennst du die Machbarkeit und musst dich daran gewöhnen, Lösungen nicht vorzugeben, obwohl du sie siehst.
Bei den Zertifikaten unterscheiden sich die Bedingungen deutlich, und das ist der Punkt, den die meisten übersehen. Für den Certified Scrum Product Owner der Scrum Alliance ist der Besuch eines Kurses Voraussetzung, und die Zertifizierung wird alle zwei Jahre über Weiterbildungsnachweise und eine Gebühr erneuert. Die Prüfungen von Scrum.org kannst du ohne verpflichtenden Kursbesuch ablegen, und sie laufen nicht ab. Beide belegen Kenntnis des Rahmenwerks, keines von beiden belegt, dass jemand Prioritäten gegen Widerstand vertreten kann.
Was im Gespräch tatsächlich zählt, ist eine Entscheidung, die du getroffen hast, und ihre Folgen. Am besten eine, bei der du etwas Gewünschtes abgelehnt oder verschoben hast, mit der Begründung, die du den Betroffenen gegeben hast, und mit dem, was danach passiert ist. Wer nur erzählen kann, wie viele Einträge er verwaltet hat, beschreibt eine Verwaltungsaufgabe.
Woran du wächst, und wohin die Rolle führt
Zwei Product Owner mit gleicher Berufsdauer unterscheiden sich an drei Stellen. Die erste ist die Fähigkeit, Nein zu sagen und die Begründung auszuhalten, ohne die Beziehung zu beschädigen. Die zweite ist der Zuschnitt: Wer große Wünsche in Schritte zerlegen kann, die einzeln nützlich sind, liefert früher etwas Verwendbares und lernt schneller. Die dritte ist die Bereitschaft, nach der Auslieferung nachzusehen, ob der erwartete Nutzen eingetreten ist, statt zum nächsten Punkt zu gehen.
Für die Bewertung von Nutzen gibt es einen brauchbaren Rahmen, der vier Blickrichtungen unterscheidet: den heute erzielten Wert, den bisher ungenutzten Wert im Markt, die Fähigkeit, überhaupt Neues zu liefern, und die Zeit von der Idee bis zur Wirkung. Der Nutzen dieses Rahmens liegt weniger in den Kennzahlen selbst als in der Frage, die er erzwingt: Woran würden wir merken, dass sich diese Entscheidung gelohnt hat.
Weiter geht es in Richtung Produktverantwortung mit größerem Zuschnitt, also über mehrere Teams oder ein ganzes Portfolio, oder in das Produktmanagement mit Markt- und Preisverantwortung. Ein Wechsel zum Scrum Master ist möglich, aber ein echter Rollenwechsel und keine Beförderung, weil du dann nicht mehr entscheidest, sondern befähigst. Und in vielen Häusern führt der Weg zurück in den Fachbereich, mit einem deutlich besseren Verständnis dafür, warum Software langsamer entsteht als erwartet.
Dazu passende Kurse
Wie eine Reihenfolge entsteht, die einer Nachfrage standhält, üben Kurse, in denen du einen Rückstand an Anforderungen nach Wert sortierst an Beispielen aus laufenden Produkten.
Wer neben der Produktverantwortung auch für Termine und Kosten geradesteht, findet in die Seminare rund um Auftrag, Termine und Budget die dafür nötigen Werkzeuge.
Warum es zu dieser Rolle keine amtliche Zahl gibt
Für den Product Owner gibt es keine amtliche Berufsgattung, weil die Rolle aus einem Rahmenwerk stammt und nicht aus der Berufssystematik: Sie beschreibt eine Verantwortlichkeit in einem Team, keinen erlernten Beruf. In der Verdiensterhebung tauchen diese Personen unter ihrem Grundberuf auf, also je nach Herkunft unter Softwareentwicklung, Wirtschaftsinformatik, Marketing oder der jeweiligen Fachrichtung des Produkts. Für die eigene Einordnung ist der Zuschnitt der Stelle die aussagekräftigere Größe: Ein Product Owner mit einem Team und ohne Budgetverantwortung ist etwas anderes als jemand, der ein Produkt mit Erlösverantwortung über mehrere Teams führt, auch wenn beide Stellen denselben Titel tragen. Wenn du dich vergleichen willst, dann mit Stellen desselben Zuschnitts in derselben Branche.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Was ist der Unterschied zwischen Product Owner und Scrum Master?
Darf der Product Owner dem Team Aufgaben zuweisen?
Kann die Rolle nebenbei ausgeübt werden?
Wie gehe ich mit Zurufen aus dem Management um?
Passt thematisch dazu
Wenn im Haus über Sprints, Backlogs und Reviews gesprochen wird, ohne dass alle dasselbe meinen, hilft ein Blick auf die Begriffe des Rahmenwerks in ihrer verbindlichen Bedeutung .
Weil du den Nutzen deiner Entscheidungen belegen sollst, gehört dazu, worauf du achten musst, damit eine Kennzahl nicht sich selbst misst .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Reihenfolge, Zuschnitt und Absagen einmal an echten Fällen üben
Ob eine Priorisierung trägt, zeigt sich erst im Widerspruch, und genau diese Gespräche lassen sich bei cmt mit Leuten durchspielen, die die Gegenseite aus ihrem eigenen Haus kennen.