Ein Unternehmen arbeitet mit mehreren Scrum Teams, um sicherzustellen, dass es die von den Kunden geforderten Termine einhalten kann. Die Teams müssen sicherstellen, dass keine Arbeiten doppelt ausgeführt werden und dass Abhängigkeiten sichtbar und eindeutig sind. Das Unternehmen hat sich für ein einziges Backlog, einen einzigen Product Owner und mehrere Scrum Teams entschieden. Jedes Scrum Team besteht aus mehreren Entwicklern und einem eigenen Scrum Master. Welche Scrum-Rolle ist am besten aufgestellt, um die Bemühungen zu koordinieren?
Answer
Die Scrum Master, weil sie Zeit haben zusammen mit den anderen Scrum Mastern zu koordinieren
Die Entwickler, weil die Teams sich selbst managen und daher auch in der Lage sein sollten, die Koordination zu übernehmen
Der Product Owner, weil der Product Owner auch das Product Backlog koordiniert
Card 82
Question
Ein Team arbeitet seit kurzem mit Scrum. Der frühere Manager ist jetzt der Product Owner des Teams. Vor dem Übergang hat der Product Owner die Aufgaben auf die Mitglieder des Teams verteilt. Der Product Owner führt dies auch nach der Übergang zu Agile fort, weil es vor der Übergang so gut funktioniert hat. Die Entwickler akzeptieren dies einfach, ohne die Angelegenheit überhaupt zu diskutieren. Sollte der Product Owner die Aufgaben auch weiterhin aufteilen?
Answer
Nein, weil die Entwickler die einzigen im Team sind, die bei Scrum Aufgaben aufteilen dürfen.
Ja, weil der Product Owner am besten aufgestellt ist, um zu bestimmen, was zu tun ist und von wem.
Ja, weil das Team großartige Ergebnisse erzielt hat, als die Aufgaben vor der Transition von diesem Mitarbeiter aufgeteilt wurden.
Nein, weil das Team nicht darüber gesprochen hat, wie sich die Aufgaben für das Team am besten aufteilen lassen.
Card 83
Question
Die einzelnen Rollen bei Scrum haben verschiedene Verantwortungen (Ergebnisverantwortungen) und Zuständigkeiten (Durchführungsverantwortungen). Eine der Rollen hat die Verantwortung, den Plan und die Arbeitsweise bei Bedarf anzupassen, um sicherzustellen, dass Fortschritt in Richtung des Sprintziels gemacht wird. Welche Rolle hat die Verantwortung dafür?
Answer
Product Owner
Scrum Master
Entwickler
Card 84
Question
Ein Scrum Team nutzt beim Sprint Planning erstmals die Definition of Done (DoD). Im Sprint Planning schätzt das Team die Größe der Backlog-Einträge (Backlog Items) und erstellt das Sprint Backlog. Warum benötigt das Team die DoD im Sprint Planning?
Answer
Weil die Arbeitsbelastung sowohl von den Anforderungen der Features als auch der DoD abhängt
Weil der Product Owner bestätigen muss, dass die Backlog-Einträge zu den Anforderungen passen
Weil jedes Feature, sobald es im Sprint abgeschlossen ist, auf Einsatzbereitschaft geprüft wird
Weil das Team das Sprintziel als potenziell lieferfähiges Produkt akzeptieren muss
Card 85
Question
Ein Product Owner verfasst für ein Product Backlog folgende User Story: Als Datentypistin möchte ich für die Verwaltung von Kundenrechnungen eine gute Benutzeroberfläche, damit ich schneller arbeiten kann. Enthält diese User Story die spezifischen Informationen, die erforderlich sind, um die Story in das Sprint Backlog zu ziehen?
Answer
Nein, die Identität des Anwendertyps ist zu unspezifisch.
Ja, sie entspricht der für eine User Story empfohlenen Vorlage.
Ja, weitere Informationen können dann während des Sprints ergänzt werden.
Nein, die Begriffe „gut“ und „schnell“ sind zu unspezifisch.
Card 86
Question
Der Scrum Master und Product Owner analysieren ein neues Product Backlog. Der Scrum Master stellt fest, dass das Product Backlog einige sehr detaillierte Stories enthält, die eine niedrigere Priorität haben. Einige der Einträge mit niedrigerer Priorität sind nicht in Epics zusammengefasst, andere schon. Die Einträge mit hoher Priorität dagegen sind überhaupt nicht in Epics zusammengefasst und sind alle sehr detailliert. Entspricht dies der Art und Weise, in der das Product Backlog verfeinert werden sollte?
Answer
Ja, weil User Stories in allen Prioritäten sowohl sehr detailliert als auch allgemein gefasst sein können.
Ja, weil die Einträge mit hoher Priorität in eines der nächsten Sprint Backlogs gezogen werden.
Nein, weil Einträge mit hoher Priorität nicht detailliert sein sollten, um unerwartete Veränderungen zu ermöglichen.
Nein, weil Stories immer zu einem Epic gehören sollten, um ein kohärentes Sprintziel zu bilden.
Card 87
Question
Die Ziele der Organisation beziehen sich auf Produkte und die Anforderungen im Product Backlog. Wie hängen diese beiden Begriffe zusammen?
Answer
Bei den Zielen der Organisation handelt es sich um Produktziele, die die Product-Backlog-Einträge (Product Backlog Items, PBIs) umfassen. Die Ziele der Organisation werden regelmäßig verfeinert, um maximalen Wert für das Unternehmen zu erzeugen. Die Produktziele sind die stabilen Elemente in der Kundenkommunikation der Organisation.
Die Ziele der Organisation sind die Ziele, die die Organisation sich selbst gesetzt hat. Um diese zu erreichen, müssen die Produktziele eines oder mehrere der Ziele der Organisation unterstützen. Die PBIs legen fest, was notwendig ist, um die Produktziele zu erreichen.
Die PBIs können in einer Portfolioansicht zusammengefasst werden. Die Ziele der Organisation unterstützen die High-Level-Produktziele als Input für die Portfolioansicht. Das obere Management nutzt die Portfolioansicht, um für ein besseres Verständnis zu sorgen, wie alle Produkte miteinander zusammenhängen.
Card 88
Question
Ein Team hat Schwierigkeiten, die für das Sprint Planning vereinbarte Timebox einzuhalten. Das Team streitet sich über die kleinsten Kleinigkeiten. Dies führt dazu, dass das Meeting stets länger dauert als festgelegt. Der Product Owner streitet mit den Entwicklern häufig über die Schätzung. Wer hat die Verantwortung (Ergebnisverantwortung) sicherzustellen, dass die Konflikte bei diesem Meeting beigelegt werden?
Answer
Der Product Owner, weil sich der Product Owner immer wieder in die Schätzung der Entwickler einmischt
Die Entwickler, weil sie sich vom Product Owner in Konflikte über Kleinigkeiten verwickeln lassen
Der Scrum Master, weil der Scrum Master die Verantwortung hat, für ein effizientes Meeting zu sorgen
Die Organisation, weil sie dem Team Möglichkeiten bieten sollte, um vernünftig zusammenzuarbeiten
Card 89
Question
Ein Scrum Master bringt einem neuen Team die Schätzung mit Story Points bei. Ein erfahreneres Teammitglied argumentiert, dass eine Schätzung mit Story Points nur für den aktuell geplanten und nicht für die kommenden Sprints nützlich sei. Das Teammitglied sagt, es sei besser in Idealtagen zu schätzen, weil diese Schätzungen auch für künftige Sprints nützlich sind, selbst wenn der Backlog-Eintrag (Backlog Item) nicht sofort in das Sprint Backlog übertragen wird. Sind Schätzungen in Idealtagen für künftige Sprints nützlicher als Schätzungen in Story Points?
Answer
Ja, weil Idealtage auf den tatsächlichen Arbeitsstunden beruhen, die sich nicht ändern.
Ja, weil Schätzungen in Idealtagen Unterbrechungen im normalen Arbeitstag zulassen.
Nein, weil eine Schätzung auf Basis von Story Points in der Regel schneller ist als eine Schätzung in Idealtagen.
Nein, weil Schätzungen mit Story Points auf einer relativen Größenangabe basieren.
Card 90
Question
Ein Team schätzt seine Geschwindigkeit. Es hat dazu bislang Folgendes unternommen: - Die Entwickler haben für eine für sie völlig neue Art von Product-Backlog-Einträgen (Product Backlog Items, PBIs) eine Prognose bezüglich der Geschwindigkeit in künftigen Sprints erstellt. - Der Scrum Master hat sich die Geschwindigkeit früherer Sprints angesehen und mehrere historische Werte notiert, die für die Schätzung der Geschwindigkeit im nächsten Sprint hilfreich sind. - Der Product Owner hat ein paar Branchenstandards der Geschwindigkeit nachgeschlagen. Welche dieser Praktiken eignet sich nicht zur Schätzung der Geschwindigkeit?
Answer
Die Verwendung von historischen Werten
Die Verwendung von Branchenstandards
Das Erstellen einer Prognose
Card 91
Question
Ein Scrum Team hat in der Vergangenheit sehr gute Leistung gezeigt. In letzter Zeit jedoch, hat das Team seine Sprintziele nicht mehr erreicht, obwohl es in jedem Sprint Zeit für Unvorhergesehenes eingeplant hat. Der Scrum Master untersucht dieses Problem gemeinsam mit dem Team in einer Sprint Retrospective. Die Entwickler identifizieren beim letzten Sprint folgende Probleme: - das Team entdeckt nach jedem Sprint ein paar Hindernisse des Arbeitsflusses - das Management kommt regelmäßig mit dringenden ungeplanten Anfragen, die immer ein paar Stunden kosten - Spezialisten werden plötzlich aus dem Team gezogen, um anderen Teams tagelang auszuhelfen - Der Product Owner hat im letzten Monat planmäßig zwei Wochen Urlaub gemacht Welches Problem ist höchstwahrscheinlich der Grund dafür, dass die Sprintziele nicht erfüllt werden?
Answer
Die Hindernisse
Die Spezialisten
Die Anfragen
Der Urlaub
Card 92
Question
Ein Team arbeitet mit einem Kanban-Board mit vier Spalten: 1 – User Story 2 – To do (zu tun) 3 – Doing (in Arbeit) (3) 4 – Done (fertiggestellt) Was ist die wahrscheinlichste Bedeutung von '(3)' in der dritten Spalte?
Answer
Dieses Team besteht aus drei Teammitgliedern und drei Doing-Spalten.
Für diese Spalte gilt eine Begrenzung der laufenden Arbeit (WIP-Limit) von drei.
Diese Spalte ist die Einzige, die in drei separate Swimlanes unterteilt ist.
Für diese Spalte gibt es drei nicht sichtbare blockierte Tickets, die es zu lösen gilt.
Card 93
Question
Was ist der Hauptzweck eines Scrum-Boards?
Answer
Es unterstützt den Scrum Master dabei, nachzuverfolgen welcher Entwickler an welcher Aufgabe arbeitet.
Es unterstützt die Entwickler dabei, ihre Arbeit zu organisieren und zeigt, wie viel Arbeit noch zu tun ist.
Es unterstützt den Product Owner dabei, die Arbeit des Teams nachzuverfolgen und Rückmeldung an die Manager zu geben.
Card 94
Question
Ein Scrum Team verfolgt seinen Fortschritt nach mit Hilfe eines Burn-Down-Charts. Im Verlauf des Sprints sieht die Kurve wie folgt aus:
Answer
Die Entwickler sind auf eine Blockade gestoßen und stecken fest.
Die Entwickler liegen bezüglich des Erreichens des Sprintziels auf Kurs.
Die Entwickler stellen weniger fertig als sie vorgesehen hatten.
Card 95
Question
Ein Team entschließt sich, auf seinem Scrum-Board Kanban-Techniken einzusetzen. Das Team hat den Begriff Begrenzung laufender Arbeit (WIP-Limit) und Blocker-Tickets eingeführt, um Hindernisse zu identifizieren, die die Fertigstellung einer Aufgabe verhindern. Der Scrum Master ist sich unsicher, was er mit den Blocker-Tickets tun soll, wenn ein Hindernis vom Board entfernt wird. Sie einfach zu entsorgen erscheint ihm irgendwie falsch. Was sollte der Scrum Master mit den Blocker-Tickets tun, um dem Team maximalen Wert zu bieten?
Answer
Er sollte die Tickets nach Lösung des Problems auf ihre Ursache untersuchen, um Hindernisse künftig zu vermeiden.
Er sollte sie zusammenfassen, um zu sehen, ob sich ein roter Faden abzeichnet, der auf eine gemeinsame Ursache vieler Probleme hindeutet.
Er sollte sie einfach als fertiggestellt (Done) kennzeichnen und entfernen, falls das Hindernis gelöst ist und nicht mehr existiert.
Er sollte sie zur Schau stellen oder in einer Sprint Retrospective bewerten, um die Entwickler daran zu erinnern.
Card 96
Question
Ein Scrum Team hat einen kritischen Bug gefunden, den es seiner Meinung nach sofort beheben muss. Das Team reserviert immer 20% der Zeit im Sprint für das Bug Fixing (Beheben von Bugs). Um die 20% der Zeit zu nutzen, hat das Team bereits einige alte Bugs in dieses Sprint Backlog gezogen. Das Team hat vereinbart, nicht mehr als 20% der Zeit auf das Bug Fixing zu verwenden. Der Product Owner hat festgestellt, dass der neue kritische Bug eine höhere Priorität hat als die Bugs, die das Team aktuell in den Sprint gezogen hat. Was ist in diesem Fall die beste Maßnahme?
Answer
Eine gleichwertige Menge an Bug-Fixing-Arbeit zugunsten der Behebung des neuen kritischen Bugs austauschen, um die 20% einzuhalten
Den neuen Bug in das Product Backlog einstellen, weil das Sprintziel und das Sprint Backlog bereits finalisiert sind
Den Sprint abbrechen, dafür sorgen, dass sich das Team auf das Bug Fixing konzentriert und nach Beheben der Bugs einen neuen Sprint starten
Die Lösung des neuen kritischen Bugs im Sprint Backlog ergänzen, selbst wenn das Team dann mehr als 20% seiner Zeit auf das Bug Fixing verwendet
Card 97
Question
Selbst in großen Entwicklungsprojekten kann es am besten sein, pro Produkt nur ein Product Backlog zu haben. Um dieses eine Product Backlog vernünftig zu managen, darf das Backlog nicht zu groß sein. Wie sollte das Product Backlog auf eine vernünftige Größe beschränkt werden?
Answer
Indem man Abhängigkeiten zwischen User Stories proaktiv eliminiert
Indem man prognostiziert, wie die nächsten Releases (Versionen) aussehen müssen
Indem man Epics nutzt und kleine Stories zu Themen zusammenfasst
Indem man Verantwortung (Ergebnisverantwortung) für das Product Backlog mit anderen teilt
Card 98
Question
Ein Unternehmen nutzt für die Skalierung eines großen Projekts einen Nexus-Ansatz. Das Nexus Integration Team koordiniert einen Sprint für alle Teams. Jedes Team hat einen eigenen Scrum Master, der dem Team beim Lösen von Blockaden hilft. Für alle Scrum Teams gibt es einen einzigen Product Owner und ein einziges Product Backlog. Ist diese Anwendung des Nexus-Ansatzes korrekt?
Answer
Ja, weil es bei einem Nexus immer nur ein einziges Product Backlog, einen Product Owner und einen koordinierten Sprint für alle Teams gibt.
Ja, weil ein Nexus-Ansatz von Unternehmen flexibel, entsprechend der Bedürfnisse des Unternehmens oder des Projekts angewendet werden kann.
Nein, weil jedes Team zur Unterstützung seiner Arbeit einen eigenen Product Owner und ein separates Product Backlog haben sollte.
Nein, weil die Teams nicht nur einen gemeinsamen Product Owner, ein gemeinsames Product Backlog und einen gemeinsamen Sprint, sondern auch einen gemeinsamen Scrum Master haben sollten.
Card 99
Question
Nicht jedes Projekt eignet sich für einen Agilen Ansatz. In einem Unternehmen liegen folgende Projekte vor. - Ein Projekt in der Personalabteilung mit knappem Budget, aber ohne festen Termin. Die Anforderungen des Projekts sind unklar. - Ein Projekt in der IT-Abteilung mit enger Frist und knappem Budget. Für eine Veränderung des Projektumfangs gibt es keinen Spielraum. Das Projekt welcher Abteilung eignet sich nicht für einen Agilen Ansatz?
Answer
Das Projekt der IT-Abteilung, weil das Budget knapp und der Termin dringend ist.
Das Projekt der IT-Abteilung, weil für die Veränderung des Projektumfangs kein Spielraum vorhanden ist.
Das Projekt der Personalabteilung, weil für das Projekt keine eindeutigen Anforderungen vorliegen.
Das Projekt der Personalabteilung, weil sich nur IT-Projekte für einen Agilen Ansatz eignen.
Card 100
Question
Ein Unternehmen möchte neben dem Scrum Team, das aktuell an einem Projekt arbeitet, ein weiteres Scrum Team nutzen. In welchem Fall ist dies eine gute Idee?
Answer
Wenn das Projekt sehr komplex ist und das aktuelle Scrum Team nicht über alle erforderlichen Kompetenzen verfügt
Wenn die Zeit für Schulung knapp ist und das aktuelle Scrum Team aus vielen unerfahrenen Mitarbeitern besteht
Wenn ein Team gerade erst die Transition abgeschlossen hat und die Mitglieder des Teams anfangs noch nicht gut zusammenarbeiten
Wenn das aktuelle Scrum Team hinsichtlich Geschlechtes, ethnischer Herkunft oder Kultur sehr divers ist
How to use this set
Read the preview and check whether the content and answers suit your learning goal. You can add the public set to your sets to study it. Your account shows the available actions.
