Questionmark Perception

Introduction

Einführung

Dies ist die EXIN Agile Scrum Product Owner Bridge (ASPOB.DE) Musterprüfung. Es gilt die Prüfungsordnung von EXIN.

Die Musterprüfung besteht aus 20 Multiple-Choice-Fragen. Zu jeder Multiple-Choice-Frage werden mehrere Antwortmöglichkeiten angeboten. Es gibt jeweils eine richtige Antwort.

Bei dieser Prüfung können maximal 20 Punkte erzielt werden. Für jede korrekte Antwort gibt es 1 Punkt. Um die Prüfung zu bestehen, müssen Sie mindestens 13 Punkte erzielen.

Die Bearbeitungszeit beträgt 45 Minuten.

Viel Erfolg!

Copyright © EXIN Holding B.V. 2021. All rights reserved.
EXIN® is a registered trademark.

Question

1 of 20

Was fällt in einem Scrum Team nicht in die Verantwortung (Ergebnisverantwortung) des Product Owners?

	Die Koordination der Produkteinführung
	Die Pflege des Product Backlogs
	Die Verwaltung des Produktbudgets
	Die Kontrolle des Fortschritts des Teams

Question

2 of 20

Der Product Owner eines Produktionsunternehmens erhält bei jedem gemeinsamen Meeting negatives Feedback vom Kunden. Der Kunde beschwert sich immer wieder, dass der Product Owner nicht das liefert, was verlangt wurde.

Was sollte der Product Owner tun, um den Erfolg des Produkts zu verbessern?

	Den Scrum Master bitten, gemeinsam mit dem Kunden eine Lösung zu erarbeiten
	Die Angelegenheit mit dem Scrum Master diskutieren und gemeinsam mit diesem eine Lösung finden
	Die Angelegenheit an die direkte Vorgesetzte der Entwickler weiterleiten
	Ein gemeinsames Meeting mit dem Kunden und dem Scrum Team organisieren

Question

3 of 20

Das interne Scrum Team einer großen Bank bereitet sein erstes Sprint Review vor. Das Team präsentiert dem Geschäft (Business) die erste Funktionalität eines Service, den es gerade baut.

Die Entwickler schlagen vor, der Product Owner solle über die bisher fertiggestellte Arbeit berichten und die Funktionalität demonstrieren. Sie argumentieren, dass der Product Owner die Kundenstimme vertrete und die Sprache des Geschäfts spreche. Die Entwickler sind der Meinung, sie selbst seien zu technisch.

Der Scrum Master dagegen schlägt vor, dass die Entwickler ihre Arbeit selbst präsentieren sollen. So hätten sie die Möglichkeit, ihre Funktionalität zu erklären und direkt auf eventuelle Fragen einzugehen. Der Scrum Master und der Product Owner werden bei dem Meeting anwesend sein.

Wie sollte das Sprint Review aufgebaut werden?

	Die Resultate werden den wichtigsten Stakeholder vom gesamten Scrum Team präsentiert und der Fortschritt in Richtung Produktziel wird erörtert.
	Der Product Owner bereitet eine Präsentation vor und präsentiert, zusammen mit den Entwicklern, den Stakeholder die Ergebnisse des Sprints.
	Der Product Owner und der Scrum Master zeigen den Stakeholder, welche Sprint-Backlog-Einträge (Sprint Backlog Items, SBIs) fertiggestellt sind.

Question

4 of 20

Ein effektives Produktziel ist einer der wichtigsten Aspekte, um in Scrum Kundenwert zu erzeugen.

Welche entscheidende Frage muss beantwortet werden, um ein effektives Produktziel festlegen zu können?

	Wie wird das Produkt für den Kunden rentabel?
	Welcher Produktzustand wird künftig erwartet?
	Zu welchem Termin soll das Produkt verfügbar sein?
	Welche Features des Produkts müssen zuerst erstellt werden?

Question

5 of 20

Amitola Company möchte ein neues Lieferantenportal schaffen, um den Lieferanten eine bessere Interaktion mit dem Unternehmen zu ermöglichen. Für das Lieferantenportal muss das Unternehmen ein Produktziel erstellen.

Der Product Owner leitet ein Meeting zur Entwicklung des Produktziels. Der Product Owner muss sicherstellen, dass alle Stakeholder dem Produktziel zustimmen. Das Produktziel ist von wesentlicher Bedeutung, um die Produktentwicklung in die richtige Richtung zu lenken.

Im Rahmen des Meetings sollte zuerst die Vision für das Lieferantenportal eindeutig herausgearbeitet werden.

Warum ist dies so wichtig?

	Weil so sichergestellt ist, dass das Team beständig auf ein werthaltiges Ziel hinarbeitet
	Weil dies hilft, den aktuellen Projektzustand zu verstehen
	Weil dies die nächste Zielbedingung ist, die bei jedem Sprint aktualisiert wird
	Weil dies das Team dazu bringt, methodisch zu experimentieren, um das Ziel zu erreichen

Question

6 of 20

Bei Scrum gibt es kein Commitment bezüglich bestimmter Features, es sei denn, diese sind aktiv in Bearbeitung. Für Kunden kann es jedoch schwierig sein, sich ohne Informationen zum Produkt auf ein Commitment zur Produktentwicklung festzulegen und ein Budget bereitzustellen. Es kann sich daher als hilfreich erweisen, den Kunden eine Produkt-Roadmap zu präsentieren.

Was ist die beste Vorgehensweise zur Erstellung einer Produkt-Roadmap?

	- Detaillierte Product-Backlog-Einträge (Product Backlog Items, PBIs) festlegen und in Gruppen einteilen - Die Lieferreihenfolge und die zur Fertigstellung benötigte Zeit festlegen - Die Roadmap in jedem Sprint Planning aktualisieren
	- Das Feedback der Entwickler und Manager zur Festlegung von Features nutzen - Bestimmen, welche Kunden mit Hilfe der Roadmap beschwichtigt werden sollten - Fortschritt und Abhängigkeiten täglich in einem Gantt-Diagramm aktualisieren
	- High-Level-Anforderungen und ein Produktportfolio festlegen - Bestimmen, welche Scrum Teams beteiligt werden - Das Product Backlog für ein vollständiges Nexus-Projekt aktualisieren
	- High-Level-Anforderungen festlegen und ordnen - Abhängigkeiten bestimmen und die Lieferreihenfolge abbilden - Roadmap im Laufe des Entwicklungsprozesses aktualisieren

Question

7 of 20

Eine Agentur für digitale Kommunikation entwickelt für einen ihrer Kunden eine Reiseplattform. Die Anwender der Reiseplattform sollen auf ein und derselben Plattform Flüge, Hotelzimmer und auch Mietwagen buchen können. Während des gesamten Projekts werden User Stories entdeckt, in Aufgaben zerlegt und verfeinert.

Folgende User Stories stehen bereit:
- Als Geschäftsreisender möchte ich nur die verfügbaren Business-Hotels sehen, damit ich schnell und effizient ein Hotel auswählen kann.
- Als Tourist möchte ich für meinen Flug ein festes Datum wählen können, damit ich meine Reise gleich bei Urlaubsbeginn antreten kann.
- Als Tourist möchte ich meine ganze Reise auf einer einzigen Plattform organisieren können, um Zeit zu sparen.

Welche User Story sollte als Epic identifiziert werden?

	Die Story über Business-Hotels
	Die Story über die festen Termine
	Die Story über die einzige Plattform

Question

8 of 20

Günter arbeitet noch nicht lange als Product Owner. Er ist sich unsicher, wie er mit nichtfunktionalen Anforderungen im Product Backlog umgehen soll.

Sobald diese wichtig werden, zerlegt er die nichtfunktionalen Anforderungen genauso in Aufgaben wie die funktionalen Anforderungen. Sobald eine Aufgabe fertiggestellt ist, die mit einer nichtfunktionalen Anforderung verbunden ist, entfernt er die nichtfunktionale Anforderung aus dem Product Backlog.

Günter stellt schon bald fest, dass er die nichtfunktionalen Anforderungen, die er zusammen mit den Stories aus dem Product Backlog entfernt, später häufig wieder hinzufügen muss.

Wie geht man mit nichtfunktionalen Anforderungen am besten um?

	Nichtfunktionale Anforderungen sollten bei Bekanntwerden in Aufgaben zerlegt und auf dem Product Backlog ganz oben eingetragen werden.
	Nichtfunktionale Anforderungen sollten in das Product Backlog eingetragen, in die richtige Reihenfolge gebracht, und sobald sie wichtig werden, in Aufgaben zerlegt werden.
	Die Stories sollten, genau so wie es aktuell gehandhabt wird, aus dem Product Backlog entfernt und bei Bedarf wieder eingetragen werden.

Question

9 of 20

Ein Team arbeitet zum ersten Mal mit Scrum. Das Team diskutiert, wie nichtfunktionale und funktionale Anforderungen zu ordnen sind. Bei funktionalen Anforderungen handelt es sich um Anforderungen, die mit dem Geschäft (Business) verbunden sind.

Wie sind nichtfunktionale Anforderungen zu ordnen?

	Sie sollten stets eine höhere Priorität haben als die mit dem Geschäft verbundenen Anforderungen.
	Sie sollten stets eine niedrigere Priorität haben als die mit dem Geschäft verbundenen Anforderungen.
	Sie sollten stets danach geordnet werden, welche Abhängigkeiten sie anderen Anforderungen auferlegen.
	Sie sollten ausgehend von der Vision des Product Owners in einem spezifischen Kontext geordnet werden.

Question

10 of 20

Welches Scrum-Artefakt muss am häufigsten aktualisiert werden?

	Die Definition of Done (DoD)
	Das Inkrement
	Das Product Backlog
	Das Sprint Backlog

Question

11 of 20

Software4You ist ein Anbieter von Software-as-a-Service (SaaS). Das Unternehmen arbeitet seit einiger Zeit mit Scrum.

Aktuell werden die getesteten Features von den Entwicklern (Development) an den Betrieb (Operations) übergeben. Dabei kommt es manchmal zwischen der Fertigstellung eines Sprints und der Freigabe der Features zu beträchtlichen Verzögerungen. Der Betrieb testet die Software häufig nochmals hinsichtlich seiner eigenen Anforderungen und findet Bugs. Alle frisch zugelassenen Features werden in vierteljährlichen Releases (Versionen) freigegeben.

Software4You möchte dies ändern, weil die Kunden des Unternehmens Verbesserungen, Bug Fixes und neue Features in kürzeren Zeitabständen fordern.

Wie lässt sich die Frequenz der Lieferung von Wert am besten steigern?

	Einen Betriebsmitarbeiter in das Scrum Team aufnehmen und ganzheitliche Testfälle als Teil der Definition of Done (DoD) verwenden. Dies trägt zum Bau einer Pipeline für kontinuierliche Lieferung bei.
	Spezielle Sprints für die Entwicklung und Bereitstellung schaffen. So kann das Betriebsteam sich in dem Sprint nach dem Entwicklungssprint mit den Testanforderungen auseinandersetzen.
	Das Betriebsteam in Scrum schulen und ein engagiertes Scrum-Betriebsteam schaffen, um die Bugs zu beheben. So kann das Team seine vierteljährlichen Releases beschleunigen und die Sprints enorm verkürzen.

Question

12 of 20

Ein Unternehmen arbeitet an einem großen Produkt. Das Unternehmen setzt zur Erledigung der Arbeit auf Teams, die in einem Nexus organisiert sind. Das Product Backlog muss über mehrere Scrum Teams hinweg skaliert werden.

Wie wird dies innerhalb eines Nexus bewerkstelligt?

	Es gibt für alle Scrum Teams innerhalb des Nexus ein Team von Product Ownern und ein einziges Product Backlog.
	Es gibt bei Nexus keine Regel, die genau beschreibt, wie das Product Backlog skaliert wird.
	Es gibt einen Product Owner und ein separates Product Backlog für jedes Nexus Scrum Team.
	Es gibt für alle Nexus Scrum Teams einen einzigen Product Owner und nur ein einziges Product Backlog.

Question

13 of 20

Bei großen Projekten arbeiten möglicherweise mehrere Scrum Teams an einem Produkt zusammenarbeiten.

Wie sollte das Product Backlog dann skaliert werden?

	Man sollte für jedes Scrum Team basierend auf den jeweiligen Komponenten ein eigenes Backlog erstellen.
	Man sollte für jedes Scrum Team basierend auf den Features ein eigenes Backlog erstellen.
	Man sollte nur ein einziges Backlog erstellen, das weder team- noch komponentenspezifisch ist.
	Die optimale Lösung gibt es nicht, wichtig ist, dass die Lösung für die jeweiligen Teams funktioniert.

Question

14 of 20

Vine Industries ist ein hippes Unternehmen im Bereich Softwareentwicklung, das für Unternehmen jeder Art und Größe maßgeschneiderte Apps entwickelt. Vine Industries arbeitet häufig in einer komplexen Entwicklungsumgebung und die Time-to-Market ist für die Kunden des Unternehmens von entscheidender Wichtigkeit.

Die Entwickler mehrerer Scrum Teams arbeiten gemeinsam an der Lieferung von Wert. Unter Umständen arbeiten an einem Produkt für einen Kunden mehrere Scrum Teams. Zwischen den von mehreren Teams entwickelten Features bestehen häufig Abhängigkeiten. Die Kunden entdecken nach jedem Sprint neue Anforderungen.

Welches Vorgehen eignet sich für die Arbeit in einer komplexen Scrum-Umgebung?

	- Ein Nexus Integration Team aufstellen, das die High-Level-Koordination übernimmt - Die Arbeit so ausrichten, dass Abhängigkeiten berücksichtigt werden - Neu identifizierte Features in den nächsten Nexus-Sprint einbinden
	- Den Prozess für die Entdeckung neuer Kundenanforderungen verfeinern - Bereits bekannte Abhängigkeiten nutzen, um zugewiesene Prioritäten aufzuheben - Einen traditionellen Release-Management-Ansatz mit Abhängigkeiten nutzen
	- Einen Design Sprint durchführen um Schwierigkeiten im Zusammenhang mit Design und Abhängigkeiten aus dem Weg zu räumen - Ein Meeting zur Releaseplanung abhalten um alle Abhängigkeiten zu planen - Backlog-Einträge (Backlog Items) in vorab festgelegte Sprints für das Release (die Version) verschieben
	- Scrum nicht mehr benutzen und komplett auf eine andere Agile Methode umstellen - Für alle Kunden einen Teil der Entwicklung auf die Überprüfung der Anforderungen aufwenden - Sprints für einen Kunden erst dann beginnen, wenn alle Anforderungen klar sind

Question

15 of 20

Das Unternehmen SHIELD arbeitet an einem neuen internen Enterprise Resource Planning (ERP) System, um das veraltete, aktuell noch verwendete System zu ersetzen. Das System wird im gesamten Unternehmen für Funktionalität sorgen und soll in allen 30 Ländern zum Einsatz kommen, in denen SHIELD auf dem Markt vertreten ist.

Das Unternehmen nutzt die traditionelle Art, Scrum zu skalieren.

Da das ERP-System aus 5 Untersystemen besteht, beschließt das Unternehmen, einen Ansatz basierend auf Komponententeams zu nutzen und ernennt 5 Product Owner. Jeder Product Owner unterstützt eines der Scrum Teams, die parallel an den einzelnen Untersystemen arbeiten. Ein Chief Product Owner wird ernannt, der das Projekt koordinieren soll.

Bei der Planung des Projekts schlagen die Teams vor, pro Komponente ein Product Backlog zu erstellen, da dieses einfacher zu pflegen und zu nutzen sei. Der Chief Product Owner lehnt diesen Vorschlag ab und sagt, dass es nur ein Product Backlog geben sollte.

Welche Entscheidung sollte in diesem Szenario bezüglich des Product Backlogs getroffen werden?

	Es sollte fünf Product Backlogs geben, weil jeder Product Owner für sein eigenes Product Backlog die Verantwortung (Ergebnisverantwortung) tragen muss.
	Es sollte zwar nur ein Master Product Backlog geben, dieses könnte aber von fünf Komponenten-Product-Backlogs begleitet werden.
	Es sollte nur ein Product Backlog geben, da mehrere Product Backlogs erhebliche Gemeinkosten und Verschwendung verursachen.
	Es sollte nur ein Product Backlog geben, weil der Chief Product Owner für das Backlog die Verantwortung trägt.

Question

16 of 20

Ein Scrum Team arbeitet hart, weiß aber nicht, ob die geleistete Arbeit zu wertvollen Features führt.

Um dem Team zu helfen, entschließt sich der Scrum Master zu Folgendem:

1. Dem Scrum Team zu helfen, die Notwendigkeit eindeutiger und klarer Product-Backlog-Einträge (Product Backlog Items, PBIs) zu verstehen
2. Sicherzustellen, dass der Product Owner weiß, wie das Product Backlog aufgebaut werden muss, um den Wert zu maximieren
3. Sicherzustellen, dass der Product Owner den gelieferten Wert im Sprint Review erklärt
4. Die Organisation bei der Übernahme von Scrum zu führen und zu coachen

Welche Kombination dieser Maßnahmen führt zu einem besseren Geschäftswert?

	1 und 2
	1 und 3
	2 und 4
	3 und 4

Question

17 of 20

Vine Solutions ist ein US-Unternehmen, das für andere Unternehmen maßgeschneiderte Software erstellt. Geschäftsziel des Unternehmens ist, das Geschäft (Business) international zu expandieren. Um dieses Ziel zu stärken, muss das Unternehmen seine Online-Präsenz ausbauen.

Der Product Owner hat mehrere Produktziele entworfen.

Welches Produktziel unterstützt das Business-Ziel von Vine Solutions am besten?

	Bau eines zuverlässig funktionierenden e-Commerce-Systems, um das Business zu unterstützen
	Ausbau der Produktion- und Lieferfähigkeit, um den Vertrieb außerhalb der US zu ermöglichen
	Neuerstellung des e-Commerce-Systems in Java, um sicher zu sein, dass das System stabil läuft

Question

18 of 20

12Bike ist ein Fahrradkurierunternehmen. Das Unternehmen möchte seine digitale Plattform verbessern, um die Einstellung und Einarbeitung (Onboarding) von neuen Fahrradkurieren zu beschleunigen.

12Bike lagert diese Arbeit an ein Softwareunternehmen aus. Das Softwareunternehmen nutzt Scrum.

Der Leiter Finanzen von 12Bike möchte die Kapitalrendite (ROI) berechnen, um sich ein Bild zu machen, welchen Wert das Projekt liefert.

Bringt die Berechnung des ROI dem Manager die Informationen, die er benötigt?

	Ja, weil der Kunde den Product Owner gebeten hat, den ROI zu berechnen.
	Ja, weil der Product Owner den ROI auf Benchmarks von Wettbewerbern beziehen kann.
	Nein, weil die Dauer des Onboardings ein viel besserer Leistungsindikator ist.
	Nein, weil der ROI nur einen Hinweis auf den Wert für das Softwareunternehmen gibt.

Question

19 of 20

Wie entwickelt man am besten ein tiefes Verständnis für die Kunden- und Anwenderbedürfnisse?

	Indem man nach dem Release (der Version) des Produkts, das Feedback des Kunden und der Anwender einholt
	Indem man die Kunden und die Anwender zur Teilnahme am Daily Scrum auffordert
	Indem man Kunden und Anwender frühzeitig und oft in den Entwicklungsprozess einbindet

Question

20 of 20

Bei der Kommunikation mit den Stakeholder kann es hilfreich sein, ein Minimum Marketable Product (Mindestmarktreife, MMP) festzulegen. Dies gibt den Stakeholder echten Diskussionsstoff.

Was versteht man unter einem MMP?

	Der minimale Satz von Features, der schnell gebaut werden können, um eine Hypothese zu testen
	Der kleinstmögliche Satz von Features, die auf die Bedürfnisse der Anwender eingehen
	Das kleinste Produkt, das die Anwender, die das Produkt umsonst bekommen, akzeptieren werden