PO-Abgrenzung [Praxis]

8 Übungsfragen mit Lösung und Erklärung.

☝️ SingleWelche Aussage über den Product Owner ist FALSCH?
✅Ein Product-Owner-Komitee teilt sich die Verantwortung für ein Produkt
❌Der Product Owner maximiert den Produktwert
❌Der Product Owner verantwortet das Product Backlog
❌Der Product Owner ist eine einzelne Person
FALSCH ist das "Komitee": Der Product Owner ist EINE Person, keine geteilte Verantwortung. Er kann Aufgaben delegieren, bleibt aber allein verantwortlich.
☝️ SingleEin sogenannter Proxy Product Owner spricht mit dem Team, während die eigentlichen Entscheidungen anderswo fallen. Welches Problem entsteht?
✅Entscheidungen verzögern sich und die Verantwortung wird unklar, denn der Ansprechpartner des Teams kann nicht entscheiden
❌Das Team arbeitet langsamer, weil es mehr Ansprechpartner hat
❌Der Scrum Master verliert seine Aufgabe
❌Keines, das ist eine übliche Arbeitsteilung
Ein Product Owner ohne Entscheidungsbefugnis ist ein Bote. Genau das untergräbt die Verantwortlichkeit und verlangsamt den empirischen Kreislauf.
☝️ SingleDer Product Owner ist für das Team fast nie erreichbar. Welche Folge ist am gravierendsten?
❌Die Sprint-Länge muss verkürzt werden
✅Die Developers treffen fachliche Annahmen selbst, wodurch am Bedarf vorbei gearbeitet wird und Nacharbeit entsteht
❌Der Scrum Master übernimmt die Product-Owner-Verantwortung
❌Das Team arbeitet ungestörter und damit schneller
Verfügbarkeit ist eine Kernanforderung an den Product Owner. Fehlt sie, entstehen stille Fehlentscheidungen, die erst spät auffallen.
☝️ SingleDarf der Product Owner die Definition of Done ändern, um einen Termin zu halten?
❌Ja, wenn die Developers zustimmen
❌Ja, einmalig pro Release
✅Nein, die Definition of Done ist keine Verhandlungsmasse für Termine; verhandelbar ist der Umfang
❌Ja, er entscheidet über das Produkt
Eine abgesenkte Definition of Done erzeugt unfertige Arbeit, die als fertig gilt. Der Preis fällt später als Nacharbeit und Vertrauensverlust an.
☝️ SingleWelche Aufgabe gehört NICHT zum Product Owner?
❌Die Reihenfolge des Product Backlogs festzulegen
✅Den Developers vorzugeben, wie sie die Arbeit technisch umsetzen
❌Das Product Goal zu entwickeln und zu kommunizieren
❌Sicherzustellen, dass das Product Backlog transparent und verständlich ist
Das Wie liegt bei den Developers. Der Product Owner verantwortet das Was und das Warum.
☝️ SingleDarf ein Product Owner den Developers vorschreiben, mit welcher technischen Lösung sie einen Eintrag umsetzen?
❌Ja, sofern er über entsprechende Fachkenntnisse verfügt
❌Ja, wenn der Scrum Master zustimmt
✅Nein – das Wie liegt bei den Developers; der Product Owner verantwortet das Was und Warum
❌Ja, bei sicherheitskritischen Anforderungen immer
Sicherheitsanforderungen sind kein Gegenbeispiel: Sie gehören als Anforderung oder in die Definition of Done, nicht als vorgegebener Lösungsweg. Der Product Owner beschreibt das Ziel, nicht die Umsetzung.
☝️ SingleEin Product Owner ist zugleich Linienvorgesetzter der Developers. Welches Problem entsteht dadurch am ehesten?
✅Die Selbstverwaltung wird ausgehöhlt, weil Priorisierungswünsche faktisch zu Anweisungen werden und Widerspruch persönliche Folgen haben kann
❌Das Product Backlog verliert seine Gültigkeit
❌Das Team kann keine Retrospektiven mehr durchführen
❌Der Scrum Guide verbietet diese Kombination ausdrücklich
Der Scrum Guide verbietet die Kombination nicht ausdrücklich, aber sie steht im Widerspruch zur Selbstverwaltung. Ein Einwand gegen den Umfang wiegt anders, wenn derselbe Mensch die Beurteilung schreibt.
✍️ OffenErklären Sie, warum die Verantwortlichkeit des Product Owners bei einer einzelnen Person liegt, auch wenn Aufgaben delegiert werden dürfen.
Musterantwort: Der Scrum Guide sieht den Product Owner als eine Person, nicht als Gremium, vor. Der Grund liegt in der Entscheidungsfähigkeit: Die Reihenfolge des Product Backlog ist eine fortlaufende Abwägung zwischen konkurrierenden, oft widersprüchlichen Interessen. Ein Gremium kann beraten, aber es entscheidet langsam, verhandelt Kompromisse statt Prioritäten und liefert dem Team keine eindeutige Antwort auf die Frage, was als Nächstes wichtig ist. Eine klar benannte Person ist ansprechbar, rechenschaftspflichtig und kann kurzfristig entscheiden, was in der empirischen Arbeitsweise unverzichtbar ist. Delegation ist dabei ausdrücklich erlaubt: Der Product Owner kann die Pflege von Einträgen, die Ausarbeitung von Akzeptanzkriterien oder die Marktbeobachtung an andere übergeben, etwa an Business Analysten oder Fachbereichsvertreter. Was nicht delegiert werden kann, ist die Rechenschaftspflicht. Er bleibt verantwortlich dafür, dass das Product Backlog transparent, verständlich und sinnvoll geordnet ist und dass das Product Goal klar formuliert ist. Damit dies funktioniert, muss die Organisation seine Entscheidungen respektieren: Wer ihn formal einsetzt, ihm aber die Entscheidungsbefugnis entzieht, erhält einen Anforderungsverwalter ohne Handlungsspielraum. Sichtbar wird eine solche Fehlkonstruktion typischerweise daran, dass Prioritäten in einem anderen Gremium festgelegt werden und der Product Owner sie lediglich weitergibt.
← Alle ThemenIm Quiz üben