Scrum Product Owner Prüfungsvorbereitung: Die 5 härtesten Prüfungsfragen

Du willst eine Karriere als Product Owner starten oder dein Wissen aus der Praxis mit einer Zertifizierung bestätigen lassen? Dann ist die Professional Scrum Product Owner™ I Zertifizierung von Scrum.org™ ein hervorragender Startpunkt.

Um zertifizierter Product Owner zu werden, musst du in der Abschlussprüfung 68 von insgesamt 80 Fragen richtig beantworten. Klingt machbar, ist es auch. Zumal es eine Reihe hilfreicher Beiträge gibt, in denen Autor:innen Tipps geben, wie man die Prüfung beim ersten Versuch bestehen kann. Doch all die gut gemeinten Tipps helfen wenig, wenn du auf die härtesten Prüfungsfragen triffst. Dann brauchst du eine ordentliche Portion Glück oder du hast diesen Artikel gelesen. Du siehst, dranbleiben lohnt sich.

Bevor wir fortfahren, noch eine wichtige Information. Du wirst die folgenden Fragen nicht wortwörtlich in der Prüfung finden. Scrum.org™ hat verständlicherweise die Veröffentlichung von Prüfungsfragen untersagt. Daher wurden die Fragen sinngemäß in die deutsche Sprache übersetzt. Aber keine Sorge: Du wirst die Fragen in der Prüfung erkennen und souverän die richtige Antwort geben können.

Doch was macht diese Fragen so schwierig? Die Gründe dafür sind:

• Für die richtige Antwort muss der Scrum Guide interpretiert werden.
• In inoffiziellen Lehrbüchern und Prüfungssimulationen werden Fragen unterschiedlich oder falsch beantwortet.
• Diskussionen im Scrum.org™ Forum, an denen sich teilweise Scrum Professionals beteiligen, kommen zu keinem eindeutigen Ergebnis.
• Die Begründung für die richtige Antwort ist im Scrum.org™ Diskussionsforum vergraben.
• Es gibt zu viele Antwortmöglichkeiten, die in Frage kommen könnten.

Das klingt jetzt erst mal abschreckend, aber lass dich nicht entmutigen. Die Einstiegsprüfungen sind in erster Linie eine Validierung von Wissen und die meisten Fragen sind deutlich einfacher als jene, die du gleich kennenlernen wirst. Legen wir los!

Frage 1: Bei meinen Aufgaben als Product Owner fokussiere ich mich auf Folgendes: (Wähle die zwei besten Antworten aus.)

1. Zusammenarbeit mit Kunden und Stakeholdern, um die wichtigsten Produktanforderungen zu ermitteln.
2. Klare Kommunikation des Projekt- oder Release-Status und der Strategien an Kunden und Stakeholder.
3. Ständige Anwesenheit im Scrum-Team, für den Fall, dass ich zur Klärung einer Anforderung beitragen kann.
4. Das Verfassen klarer, transparenter User Stories.

Hast du dich für zwei Antwortoptionen entschieden? Sehr gut! Dann lass uns prüfen, ob deine Antworten richtig sind. Starten wir mit einem Ausschlussverfahren. Antwortmöglichkeit 3 ist mit Sicherheit falsch. Product Owner müssen nicht ständig beim Scrum Team sein. Beispielsweise ist das Daily Scrum ein Event für Developer, bei dem Product Owner als Zuhörer dabei sein können, allerdings nicht müssen.

Nun wird es spannender, denn alle 3 verbleibenden Antwortmöglichkeiten können als Antwort in Frage kommen. Eine Recherche im Internet bringt leider auch keine weitere Klarheit, sondern verwirrt zusätzlich, da die Frage auf verschiedenen Portalen unterschiedlich beantwortet wird. Grenzen wir also weiter ein. Am richtigsten ist die Antwortoption 1, denn im Scrum Guide steht: „Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.“ … „Der:die Product Owner:in kann die Bedürfnisse vieler Stakeholder:innen im Product Backlog berücksichtigen.“ Dafür müssen Product Owner mit Kunden und Stakeholdern zusammenarbeiten.

Bleiben noch die beiden Antwortoptionen 2 und 4. Jetzt wird es richtig schwierig, denn beide Antwortmöglichkeiten erfordern eine Interpretation des Scrum Guides. Zur Erinnerung: Die Frage zielt auf den Fokus ab, den Product Owner setzen sollen. Ist es wichtiger, die Erwartungen der Kunden und Stakeholder zu managen oder sollte das Verfassen von klaren, transparenten User Stories im Fokus stehen? Beide Aufgaben können Product Owner delegieren. Doch welche Aufgabe sollte besser beim Product Owner bleiben?

Eine User Story ist eine Einladung zu einem Gespräch. Product Owner erklären das Problem, erläutern die Hintergründe und beschreiben die Anforderungen. Im Dialog mit den Developern entsteht ein gemeinsames Verständnis. Auf dieser Basis können die Developer eigenständig User Stories verfassen. Diese Herangehensweise macht auch deswegen Sinn, weil die Entwickler:innen schlussendlich dafür verantwortlich sind, ein nutzbares Product Increment zu schaffen.

Das Erwartungsmanagement von Kunden und Stakeholdern bleibt in den meisten Fällen bei den Product Owner, weil sich aus der Zusammenarbeit mit ihnen wichtige Impulse für die Produktweiterentwicklung ergeben.

Daraus folgt, dass neben der Antwortoption 1 ebenso die Antwortoption 2 richtig ist.

Weiter geht’s zur nächsten Frage.

Frage 2: Während der Sprint Retrospektive hat ein Scrum Team mehrere Prozessverbesserungen mit hoher Priorität identifiziert. Welche der folgenden Aussagen ist am zutreffendsten? (Wähle die beste Antwort.)

1. Das Scrum Team soll mindestens eine Prozessverbesserung mit hoher Priorität auswählen, die in das Sprint Backlog aufgenommen wird.
2. Das Scrum Team soll mindestens eine Prozessverbesserung mit hoher Priorität auswählen, die in das Product Backlog aufgenommen wird.
3. Der Scrum Master wählt die wichtigste Prozessverbesserung aus und platziert diese im Sprint Backlog.
4. Das Scrum Team sollte es ablehnen, eine Prozessverbesserung in das Sprint Backlog aufzunehmen, wenn die Dinge reibungslos laufen.

Wäre die Zeit im Jahr 2017 stehen geblieben, dann wäre die Antwort auf die Frage sehr einfach, denn im Scrum Guide vom November 2017 ist folgender Satz zu finden:

„Zum Ende der Sprint Retrospective sollte das Scrum Team Verbesserungen für den kommenden Sprint identifiziert haben. Die Umsetzung dieser Verbesserungen im nächsten Sprint ist die Anpassungsleistung zur Selbstüberprüfung des Scrum Teams.“

Demzufolge war damals die Option 1 die richtige Antwort. Doch in der 2020er Version des Scrum Guides ist dieser Satz nicht mehr zu finden. Stattdessen ist folgende Aussage zu finden:

Der letzte Satz impliziert, dass keine Prozessverbesserung direkt im Sprint Backlog platziert werden muss. Stellt sich die Frage, wie mit Prozessverbesserungen umgegangen werden soll.

Die Antwort liefert uns der Foren-Beitrag „Where is the „high priority process improvement“ identified during Sprint Retrospective placed?“ auf Scrum.org™. Dort kommentierte Eric Naiburg (Chief Operating Officer bei Scrum.org™):

… having talked to Ken [Ken Schwaber – einer der Gründer des Scrum Frameworks] about that [Where is the „high priority process improvement“ identified during Sprint Retrospective placed?], you hit the nail on the head. He added it originally because he felt that it was too easy for a PO to ignore the process improvement and focus only on features, so making it mandatory felt right. After feedback, it was moved to Product Backlog to give the whole team visibility and allowing the whole team to decide if it should move into a Sprint. Less prescriptive…

Damit ist es amtlich. Antwortoption 2 ist richtig.

Frage 3: Wer hat die finale Entscheidungskompetenz darüber, ob ein Inkrement released wird oder nicht?

1. Developer
2. Stakeholder
3. Scrum Master
4. Product Owner
5. Scrum Team

Werfen wir einen Blick in den aktuellen Scrum Guide. Die Antwort finden wir dort nicht – das wäre auch zu einfach, für eine der härtesten Prüfungsfragen – allerdings stehen dort Aussagen, die uns bei der Herleitung der richtigen Antwort helfen könnten. Beispielsweise:

„Das Scrum Team ist umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholdern, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte.“ Daraus könnte interpretiert werden, dass das Scrum Team darüber entscheidet, ob ein Inkrement releast wird oder nicht.

Dem widerspricht allerdings die Aussage: „Damit ein Product Owner Erfolg haben kann, muss die gesamte Organisation seine Entscheidungen respektieren.“ Also liegt die finale Entscheidungskompetenz doch bei Product Ownern

Einen Hinweis auf die Antwort liefert wieder eine Diskussion im Scrum.org™ Forum. Im Beitrag „Who is responsible for release decision – PO or Scrum Team?“ finden wir folgendes Kommentar von Eric Naiburg: „… there were a lot of discussions leading to that change in the 2020 guide and reality is that there may be factors beyond the Product Owner or Scrum Teams abilities that come into play. For example in banking there could be regulatory factors. So hopefully it is a collaborative decision and the PO should be involved and there may be things beyond their control.“

Demnach ist also die richtige Antwort das Scrum Team. Doch so richtig überzeugt war ich noch nicht. Deswegen habe ich die Chance ergriffen und die Frage unabhängig voneinander den beiden Professional Scrum Trainer:innen Daria Bagina (Q&A) und Magdalena Kucharska (Ask a Professional Scrum Trainer) gestellt. Beide sind zu dem gleichen Ergebnis gekommen: Product Owner.

Hättest du die Antworten auf die drei Fragen gewusst? Wenn ja, dann bist du mit deiner Prüfungsvorbereitung schon richtig gut unterwegs. Falls du die eine oder andere Frage nicht richtig beantworten konntest, Kopf hoch, denn die meisten Fragen in der Prüfung sind deutlich einfacher!

Frage 4: Wobei hilft der „Cone of Uncertainty“? (Wähle die beste Antwort aus.)

1. Zur Vorhersage, was bis zu einem bestimmten Sprint abgeschlossen sein wird.
2. Zur Schätzung der Kosten für ein Projekt, bevor es begonnen wird.
3. Um festzustellen, ob Abstriche bei der Qualität gemacht werden sollen.
4. Zur Verdeutlichung, dass je länger eine Vorhersage ist, sie desto unsicherer ist.

Diese Frage ist aus dreierlei Gründen besonders schwierig. Erstens liefert der Scrum Guide überhaupt keine Hinweise darüber, welche Antwort die Richtige sein könnte, zweitens kommen Diskussionen auf Scrum.org™ zu keinem eindeutigen Ergebnis und drittens wird die Frage in inoffiziellen Lehrbüchern und Prüfungssimulationen unterschiedlich beantwortet.

Was ist eigentlich dieser „Cone of Uncertainty“? Es handelt sich um ein Konzept, das den Verlauf von Unsicherheiten in einem Projekt beschreibt. Je weiter ein Ereignis in der Zukunft liegt, desto weniger wissen wir darüber. Deswegen sind Schätzungen über Ereignisse, die weit in der Zukunft liegen, ungenau, verschwommen oder sogar falsch. Je näher wir einem Ereignis kommen, desto mehr lernen wir darüber, desto genauer werden Schätzungen und Vorhersagen. Kurzum. Der „Cone of Uncertainty“ hilft, mit Unsicherheit umzugehen.

Von dieser Definition her kommend ist die Antwortoption 4 richtig. Ein Fragezeichen taucht allerdings auf, wenn wir einen Blick auf die englischsprachige Wikipedia Seite zum „Cone of Uncertainty“ werfen. Dort finden wir unter anderem die Aussage „However, the concept, under different names, is a well-established basic principle of cost engineering.“ Demnach wäre auch die Antwortoption 2 richtig. Allerdings wird der Beitrag mit der Information eingeleitet, dass es sich um ein Konzept handelt, das den Verlauf von Unsicherheit in einem Projekt beschreibt. Daher kann angenommen werden, dass die Antwortoption 4 richtig ist.

Frage 5: Richtig oder falsch: Alle von den Developern geplanten Arbeiten für das Produkt stammen aus dem Product Backlog.

1. Richtig
2. Falsch

Im Scrum Guide steht: „Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden. Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird.“ Demnach wäre die Antwortoption 1 richtig. Ganz so einfach ist es dann doch nicht, denn im Scrum Guide steht ebenso: „Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde.“ Hieraus könnte interpretiert werden, dass die geplante Arbeit auch direkt im Sprint Backlog erstellt werden darf.

Um die Antwort herauszufinden, müssen wir auf jedes Wort in der Frage achten und einen Teil des Planungsprozesses rückwärts betrachten. Entscheidend für die Beantwortung der Frage ist das unscheinbare Wort „geplant“. Der kurzfristige Plan im Scrum Framework ist das Sprint Backlog. Dazu finden wir im Scrum Guide folgende Aussage: „Das Sprint Backlog besteht aus dem Sprint-Ziel (Wofür), den für den Sprint ausgewählten Product-Backlog-Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie).“ Die Quelle für das Sprint Backlog sind also ausgewählte Product Backlog Einträge aus dem langfristigen Plan, dem Product Backlog. Damit wird offensichtlich, dass die Antwortoption 1 richtig ist.

Noch ein kleiner Nachtrag zu „Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde.“ Hier geht es um die Anpassung des Plans, nicht um die Planerstellung.

Damit nähern wir uns dem Ende des Artikels. Ich hoffe, das entzaubern der härtesten Prüfungsfragen hat dir Spaß gemacht. Viele der Fragen in der Prüfung sind deutlich einfacher, trotzdem wirst du jetzt auch die schwierigsten Fragen meistern können. Wenn du mehr über die Aufgaben des Product Owners im Rahmen des Scrum Framework lernen möchtest, dann besuche doch unser Product Management / Product Ownership Training. Vor Ort oder remote lernst du Werkzeuge, Methoden und Techniken kennen, die dich zur erfolgreichen Produktmanager:in oder Product Owner machen.

Um auch die kleinen Hürden als Product Owner im Alltag zu meistern, haben wir einen Product Owner Cheat Sheet erstellt, der hier zum Download steht.