[2023] Neue PSPO-I-Prüfung Kostenlose Musterfragen zum Üben [Q179-Q196]

* Die beste Aussage, die Scrum beschreibt, ist: Ein Rahmenwerk zur Schaffung von Werten durch adaptive Lösungen für komplexe Probleme.
* Scrum ist ein leichtgewichtiges Framework, das Menschen, Teams und Organisationen dabei hilft, in komplexen und unsicheren Umgebungen wertvolle Produkte zu liefern.
* Scrum basiert auf Empirie, was bedeutet, dass Wissen aus Erfahrung entsteht und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden. Scrum verwendet einen iterativen und inkrementellen Ansatz, um die Vorhersagbarkeit zu optimieren und Risiken zu kontrollieren.
* Scrum ist kein definierter und vorhersehbarer Prozess, keine vollständige Methodik oder ein Kochbuch, in dem die besten Praktiken festgelegt sind. Scrum bietet die minimalen Grenzen, innerhalb derer sich Teams selbst organisieren und innovative Lösungen schaffen können. Referenzen: Scrum-Leitfaden, Abschnitt 1 (Definition von Scrum) und Abschnitt 2 (Einsatzmöglichkeiten von Scrum)

Erläuterung
Scrum schreibt nicht vor, dass der Product Owner eines der folgenden Elemente verwenden muss:
* Burndown-Diagramm: Ein Burndown-Diagramm ist eine grafische Darstellung der noch zu erledigenden Arbeit im Verhältnis zur Zeit. Es kann verwendet werden, um den Fortschritt zu verfolgen und die Fertigstellungstermine von Projekten oder Sprints vorherzusagen. Es ist jedoch in Scrum nicht zwingend vorgeschrieben. Es ist eine der möglichen Techniken, die ein Product Owner verwenden kann, um die Produktentwicklung zu überwachen und zu kommunizieren.
* Feature-Burn-up: Ein Feature-Burn-up-Diagramm ist eine grafische Darstellung der abgeschlossenen Features im Vergleich zur Zeit.
Es kann verwendet werden, um den Fortschritt zu verfolgen und Umfangsänderungen von Projekten oder Sprints vorherzusagen. Es ist jedoch in Scrum nicht zwingend vorgeschrieben. Es ist eine der möglichen Techniken, die ein Product Owner zur Überwachung und Kommunikation der Produktentwicklung einsetzen kann.
* Analyse des kritischen Pfades: Die Analyse des kritischen Pfades ist eine Projektmanagementtechnik, mit der die Reihenfolge der Aufgaben ermittelt wird, die rechtzeitig abgeschlossen werden müssen, damit ein Projekt oder ein Sprint planmäßig beendet werden kann. Sie kann verwendet werden, um komplexe Projekte oder Sprints zu planen, zu überwachen und zu steuern. Sie ist jedoch in Scrum nicht zwingend vorgeschrieben. Es ist eine der möglichen Techniken, die ein Product Owner zur Steuerung der Produktentwicklung einsetzen kann.
* Projekt-Gantt-Diagramm: Ein Projekt-Gantt-Diagramm ist eine grafische Darstellung von Aufgaben, Abhängigkeiten, Laufzeiten und Meilensteinen eines Projekts oder Sprints. Es kann verwendet werden, um komplexe Projekte oder Sprints zu planen, zu überwachen und zu steuern. Es ist jedoch in Scrum nicht zwingend erforderlich oder vorgeschrieben. Es ist eine der möglichen Techniken, die ein Product Owner zur Steuerung der Produktentwicklung einsetzen kann.
Die richtige Antwort lautet daher: keine der oben genannten Fragen.
Referenzen:
* [Scrum Guide], Seite 6, Abschnitt "Product Owner".
* [Scrum Guide], Seite 11, Abschnitt "Product Backlog"
* [Professional Scrum Product Owner Training], Seite 8, Abschnitt "Release Management"

Erläuterung
* In Scrum gibt es nur ein Produkt und ein Product Backlog für ein bestimmtes Produkt. Das Product Backlog ist die einzige Quelle der Wahrheit für das Scrum-Team und die Stakeholder. Es enthält alle Anforderungen, Merkmale, Funktionen, Erweiterungen, Korrekturen und alles andere, was den Kunden und Benutzern des Produkts einen Mehrwert bieten kann. Das Product Backlog wird vom Product Owner auf der Grundlage der Produktvision, der Ziele und des Werts geordnet.
* Mehrere Product Backlogs für ein Produkt würden zu Verwirrung, Doppelarbeit, Inkonsistenz und Verschwendung führen. Außerdem würde es dadurch schwieriger, die Scrum-Teams und die Stakeholder auf die gleiche Produktrichtung und die gleichen Prioritäten auszurichten. Daher sollte nicht jedes Scrum Team ein eigenes Product Backlog haben.
* Der Product Owner ist für die Maximierung des Wertes des Produkts verantwortlich, das aus der Arbeit des Scrum-Teams resultiert. Der Product Owner ist dafür verantwortlich, das Product Backlog zu verwalten und zu verfeinern, mit den Stakeholdern und den Entwicklern zusammenzuarbeiten und die Elemente so anzuordnen, dass die Ziele und Aufgaben am besten erreicht werden. Der Product Owner vertritt die Interessen aller am Produkt Beteiligten und sorgt dafür, dass das Scrum Team zur richtigen Zeit an den richtigen Dingen arbeitet.
* Mehrere Product Owner für ein Produkt zu haben, würde zu Konflikten, Überschneidungen, Lücken und Ineffizienzen führen. Außerdem würde es dadurch schwieriger, eine klare und konsistente Produktvision, Strategie, Roadmap und Backlog zu erhalten. Daher sollte es nur einen Product Owner für ein Produkt geben.
* In einigen Fällen, wenn mehrere Scrum-Teams an einem Produkt arbeiten, kann es notwendig sein, eine Form von Skalierungs- oder Koordinierungsmechanismus zu haben, um die Ausrichtung und Zusammenarbeit zwischen den Teams zu gewährleisten. Das bedeutet jedoch nicht, dass es mehrere Product Owner oder Product Backlogs geben sollte.
Stattdessen sollte es Wege geben, die Kommunikation, das Feedback, die Integration und die Transparenz zwischen den Teams und mit dem Product Owner zu erleichtern. Einige Frameworks oder Praktiken, die bei der Skalierung von Scrum helfen können, sind zum Beispiel Nexus, LeSS, SAFe oder Scrum of Scrums.
Referenzen:
* Scrum-Leitfaden: https://www.scrumguides.org/scrum-guide.html
* Nexus: https://www.scrum.org/resources/what-is-nexus
* LeSS: https://less.works/
* SAFe: https://www.scaledagileframework.com/
* Scrum of Scrums: https://www.agilealliance.org/glossary/scrum-of-scrums/

Erläuterung
Es ist nicht wahr, dass ein Product Owner klare und eindeutige Akzeptanzkriterien für jedes Product Backlog Item erstellen muss, bevor es im Sprint Planning ausgewählt werden kann. Der Grund dafür ist:
* Abnahmekriterien sind eine Reihe von Bedingungen, die ein Product Backlog Item erfüllen muss, um vom Product Owner oder den Stakeholdern akzeptiert zu werden. Sie werden verwendet, um zu überprüfen, ob das Element die erwarteten Qualitäts- und Wertstandards erfüllt.
* Abnahmekriterien sind in Scrum nicht zwingend erforderlich oder vorgeschrieben. Sie sind eine der möglichen Techniken
*, die ein Product Owner verwenden kann, um seine Erwartungen und Anforderungen an die Entwickler und die Stakeholder zu kommunizieren. Sie sind nicht Teil des Scrum-Leitfadens oder der Definition von Done.
* Akzeptanzkriterien müssen nicht vor der Sprintplanung erstellt werden. Sie können jederzeit während des Produktentwicklungsprozesses erstellt oder verfeinert werden, solange sie klar sind und vereinbart wurden, bevor das Element als fertiggestellt gilt. Sie können auch auf der Grundlage von Feedback oder neuen Erkenntnissen geändert oder aktualisiert werden.
* Die einzige Voraussetzung für die Auswahl eines Product-Backlog-Elements in der Sprint-Planung ist, dass es ausreichend klar und auswählbar ist. Das bedeutet, dass es genügend Details und Präzision aufweist, damit die Entwickler verstehen, was sie bauen sollen und warum. Es bedeutet auch, dass es vom Product Owner auf der Grundlage von Wert und Auswirkungen verfeinert und geordnet wurde.
Referenzen:
* [Scrum Guide], Seite 14, Abschnitt "Sprint Planning"
* [Scrum Guide], Seite 12, Abschnitt "Product Backlog Refinement"
* [Professional Scrum Product Owner Training], Seite 7, Abschnitt "Product Backlog Management"

Erläuterung
* Der Product Owner ist eine Person, kein Ausschuss oder ein Team von Personen. Der Product Owner ist für die Maximierung des Werts des Produkts verantwortlich, das aus der Arbeit des Scrum-Teams resultiert. Der Product Owner ist dafür verantwortlich, das Product Backlog zu verwalten und zu verfeinern, mit den Stakeholdern und den Entwicklern zusammenzuarbeiten und die Elemente so anzuordnen, dass die Ziele und Aufgaben am besten erreicht werden.
Der Product Owner vertritt die Interessen aller am Produkt Beteiligten und sorgt dafür, dass das Scrum-Team zur richtigen Zeit an den richtigen Dingen arbeitet.
* Mehrere Product Owner für ein Produkt zu haben, würde zu Konflikten, Überschneidungen, Lücken und Ineffizienzen führen. Außerdem würde es schwieriger werden, eine klare und konsistente Produktvision und -strategie aufrechtzuerhalten,
* Roadmap und Backlog. Daher kann das Scrum-Team nicht mehrere Product Owner haben.
* Der Product Owner ist für die Anordnung des Product Backlogs verantwortlich. Das Product Backlog ist eine geordnete Liste von allem, von dem bekannt ist, dass es für das Produkt benötigt wird. Es ist die einzige Quelle der Wahrheit für das Scrum-Team und die Stakeholder. Es enthält alle Anforderungen, Merkmale, Funktionen, Erweiterungen, Korrekturen und alles andere, was den Kunden und Benutzern des Produkts einen Nutzen bringen kann. Der Product Owner ordnet die Elemente im Product Backlog anhand von Faktoren wie Wert, Risiko, Priorität, Abhängigkeit, Feedback oder Marktbedingungen.
Referenzen:
* Scrum-Leitfaden: https://www.scrumguides.org/scrum-guide.html
* Produkteigentümer: https://www.scrum.org/resources/what-is-a-product-owner
* Product Backlog: https://www.scrum.org/resources/what-is-a-product-backlog