Scrum Master German Prüfung - TrueAgile - the meta institute for Agility and Innovation

Welcome to your Scrum Master German

Welche fünf Scrum Werte gibt es?

Transparenz, Inspektion, Anpassung, Fokus, Mut

Mut, Respekt, Commitment, Fokus, Offenheit

Selbstorganisation, Eigenverantwortung, Priorisierung, Transparenz, Commitment

Respekt, Mut, Commitment, Transparenz, Offenheit

Welche Aussage trifft auf Stakeholder in Scrum zu?

Stakeholder sind Vertreter unserer internen und externen Kunden und geben uns Feedback zu unserem Produktfortschritt im Sprint Review

Stakeholder bilden das Management in Scrum und steuern das Scrum Team durch das Sprint Review

Stakeholder sind ein wichtiger Teil des Scrum Prozesses und nehmen zusätzlich zum Sprint Review auch an der Sprint Planung teil

Stakeholder sind Vertreter aus dem Management und geben uns Feedback zum unserem Arbeitsfortschritt im Sprint Review

Wie sollte eine optimale Sprint Planning vorbereitet werden?

Der Scrum Master in Abstimmung mit dem Team, das Sprintziel, die Backlog Items und den Raum für das Planning vorbereitet haben

Der Product Owner sollte einen Vorschlag für das Sprint Ziel und das Refinement der dafür benötigten Backlog Items sicherstellen

Das Scrum Team sollte das Product Backlog Refinment direkt vor dem Sprint Planning durchführen.

Die Developer sollten das Sprintziel und die benötigten Backlog Items und dazugehörigen Aufgaben vorbereitet haben

Als Product Owner verantwortest du den Product Backlog. Wie stellst du sicher, dass die richtigen Dinge durch das Team zuerst bearbeitet werden?

Ich kann den Scrum Master im Daily überprüfen lassen, ob das Team auch an den richtigen Dingen arbeitet

Im Sprint Planning kann ich meine Prioriäten gegenüber dem Team durch die zu bearbeiten Items und das Sprint Ziel klar darstellen.

Ich installiere ein Meeting pro Woche in dem ich mir den Arbeitsfortschritt zu wichtigsten Items zeigen lasse.

Im Daily Stand up kann ich die Developer auf die Prioriäten hinweisen, sodass sie nicht die falschen Aufgaben zuerst bearbeiten

Was sind die fünf Scrum Events?

Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Scrum Management Meeting

Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Sprintend Meeting

Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

Was ist zu beachten wenn es um die Definition of Done geht?

Die Definition of Done ist ein zentrales Dokument der Entwicklung und wird bei der Abnahme als Qualitätsmaßstab benutzt.

Die Definition of Done gilt für alle Backlog Items sichert die Qualität eines Increments ab.

Die Definition of Done beschreibt, wann das Produkt "Done" ist und gilt daher über das gesamte Projekt.

Die Definition of Done beschreibt wann die Developer den Sprint abgeschlossen haben.

Wer lädt die Stakeholder in das Sprint Review ein?

Der Product Owner

Niemand, die Stakeholder kommen einfach

Die Developer

Der Scrum Master

Das Managementteam beklagt nach einiger Zeit dass sich ein Team nicht mehr an die Unternehmensprozesse hält. Es sieht ein geschäftliches Risiko bei der Missachtung wichtiger Unternehmensstandards. Wie verhälst du dich?

Du lädst alle zu einem Meeting ein und erklärst dem Team, dass es wichtig ist die Unternehmensprozesse einzuhalten und welche Risiken sonst eintreten können.

Du verweist auf die gemeinsame Vereinbarungen, welche zu Beginn des Projektes geschlossen wurde und bittest das Management das Team in Ruhe zu lassen

Du organisierst in Absprache mit dem Team einen Termin in dem sich das Management und das Team über die Gründe und Risiken der Nichteinhaltung austauschen können.

Du erklärst dem Management das agile Teams keine Prozesse brauchen und verweist auf das agile Manifest, dass Inviduen und Interaktionen wichtiger sind als Prozesse und Werkzeuge

Für was ist ein Product Owner verantwortlich? Wähle die passenste Aussage

Die Erstellung eines priorisierten Product Backlogs

Aufgabenverteilung an das Team im Sprint Planning

Priorisierung der Tasks für die Developer im Daily Stand-up

Lösen von Impediments in der Retrospektive

Du bist neu als Scrum Master im Unternehmen und das Managementteam erklärt dir, dass Scrum sich nicht stark von klassischen Arbeitsweisen unterscheidet. Wie reagierst du?

Du stimmst zu, da das Management recht hat und versuchst in der Praxis pragmatisch mit Problemen umzugehen

Du stimmst zu, da du die Unterstützung des Management brauchst und versuchst sie durch die Praxis vom Gegenteil zu überzeugen

Du widersprichst und zeigst ihnen anhand von Praxis Beispielen aus deiner Erfahrung warum sie falsch liegen

Du versuchts herauszufinden, warum das Managementteam daran glaubt. Gemeinsam arbeitet ihr an einem Beispiel den Unterschied für das Managementteam erlebbar zu machen.

Wie sollen die Items im Sprint Backlog jeden einzelnem Teammitglied zugeordnet werden?

Nach dem Push-Verfahren: Der Scrum Master weist die Aufgaben im Daily Stand up zu

Nach dem Push-Verfahren: Der Product Owner weist die Aufgaben im Sprint Planning zu

Nach dem Pullverfahren: Im Daily Stand Up ziehen sich die Developer die Aufgaben aus dem Sprint Backlog

Nach dem Pullverfahren: Im Planning verteilen die Developer alle Aufgaben des Sprints

Nach jedem Sprint muss es einen Release für den Kunden geben.

Falsch - Das Team kann jederzeit an den Kunden ausliefern

Falsch - Am Ende eines Sprint muss Increment ledegilich potenziell auslieferbar sein

Richtig - Aber nur wenn der Kunde es im Sprint Planning bestellt hat

Richtig - Regelmäßige Auslieferungen an den Kunden sind wichtig.

Welche Aussage trifft auf ein Backlog Item zu, welches als "Done" bezeichnet wird?

Ein Backlog Item ist "Done" wenn alle Akzeptanzkriterien und die Definition of Done erfüllt ist und kein Restaufwend mehr übrig sind

Wenn der Product Owner das Item im Sprint Review mit den Stakeholdern abgenommen und als "Done" deklariert hat

Wenn alle dazugehörigen geplanten Aufgaben als "Done" markiert sind und keine weiteren Aufgaben auf dem Board sind

Wenn der Scrum Master im Daily das Product Backlog Item abgenommen hat und es als "Done" deklariert

Das Product Backlog ist das das selbe wie ein klassischer Projektplan nur bestehen die Arbeitspakete aus Stories...

Ja, jedoch können auf Änderungen durch die Story-Struktur besser reagiert werden.

Ja, deshalb ist es auch nicht schwer einen klassischen Projektplan aufzubauen

Nein, das Product Backlog besteht auch aus Epics, Features und Tasks und nicht nur aus Stories

Nein, ein Product Backlog beinhaltet einen priorisierte Liste der Anforderungen des Produktes

Das Team plant im Sprint Planning den Sprint Backlog… Wie detailliert muss die Planung der Developer sein?

Die Developer ordnen den Aufgaben Verantwortungen zu und planen sie dann selbstorgansieiert

Jeder Developer plant mit dem Scrum Master die Aufgaben so, dass eine persönliche Überprüfung durch den Scrum Master im Daily Stand up möglich ist

Die Developer planen so, dass jede Aufgabe einen Verantwortlichen hat und der Product Owner nachvollziehen kann, dass das Sprintziel erreicht wird

Die Developer planen die Aufgaben so, sie das Sprintziel realisitisch erreichen und den Arbeitsfortschritt verfolgen können

Was ist eine gute Representation eines Cross-Funktionalen Teams?

Möglichst viele Entwickler aus einem Fachbereich.

Alle Entwickler die benötigt werden um die Funktionen zu entwickeln

Alle Funtkionen, die zur Realisierung des Produktes benötigt werden

Einen Scrum Master, Einen Product Owner und mindestens 3 Developer.

Wer ist für die Erstellung des Product Goals verantwortlich?

Der Scrum Master

Die Stakeholder

Der Product Owner

Das Management Team

Welche Aussage trifft auf das Management in Scrum zu?

Das Management gibt wertvolles Feedback zum Scrum Prozess

Das Scrum Team hat kein Management. Es managet sich selbst.

Das Management organisiert das Team und wird durch den Scrum Master repräsentiert

Das Management gibt wertvolles Feedback zum Produktfortschritt

Wann findet die Sprint Retrospective am Ende des Sprints statt?

Immer nach dem Sprint Planning, um die Planung auf Veränderung anzupassen.

Am Anfang eines Sprints, um gut auf das Sprint Planning vorbereitet zu sein.

In der Mitte des Sprints, hier können noch rechtzeitig anpassung in der Zusammenarbeit gemacht werden, damit das Sprint Review stattfinden kann.

Am Ende eines Sprints. hat das Team die Ruhe und Zeit um die Zusammenarbeit zu reflektieren

Du bist ein Scrum Master in einem neuen Team. Dein Scrum Team hat sich in der Retrospective dafür entschieden 2 Dailies pro Woche, weil es nichts zu berichten hat. Was ist eine sinnvolle Reaktion?

Du lässt das Team weiterarbeiten, da das Team selbstorganisiert eine Entscheidung getroffen hat.

Du beobachtest die Dailies und versuchst in der Retrospektive herauszufinden, warum das Team diese Entscheidung getroffen hat.

Du führst sofort wieder 5x die Woche das Daily ein, da du als Scrum Master die Authorität über dem Scrum Prozess hast

Du fragst das Scrum Team, wie es zur Entscheidung gekommen ist und schlägst dann vor wieder 5x pro Woche zu machen, wie es vom Srum Guide vorgesehen ist.

Ein Mitglied des Management Team ist mit seiner Rolle als Stakeholder unzufrieden und möchte stärker eingebunden. Was ist die wahrscheinlich beste Vorgehensweise als Scrum Master?

Du setzt dich mit dem Stakeholder zusammen und versuchst herauszufinden, was genau das Bedürfnis des Stakeholder ist.

Wenn der Stakeholder stärker eingebunden werden möchte, muss er Teil der Developer werden und seine Stakeholder Rolle verlassen.

Der Stakeholder darf nach Zustimmung des Teams mit an den Dailys teilnehmen.

Du nimmst den Stakeholder in Abstimmung mit dem Team als Experten mit ins Planning.

Du bist als neuer Scrum Master bei deinem ersten Daily. Du siehst dass der Product Owner das Daily Stand-up moderiert und Aufgaben im Team für den Tag verteilt. Was machst du?

Du hälst das Daily an und übernimmst die Moderation vom Product Owner.

Du beobachtest das Daily weiterhin und gibst am Ende deine Beobachtung ins Team und erklärst wie das ursprünglich funktioniert.

Du hälst das Daily an und nimmst dir den Product Owner direkt vor. Das Team soll schließlich selbstorganisert sein

Du hälst das Daily an und bestimmst einen Developer für die Moderation. Das Team ist schließlich selbstorganisiert

Du bist ein Scrum Master von zwei Teams. Dein Management fragt dich, wie wir die Teams hinsichtlich ihrer Leistung vergleichen können?

Du erwirderst dass Teams sich nicht hinsichtlich ihrer Leistung nicht mit einer messbaren und einheitlichen Größe vergleichen lassen.

Teams können über die Story Point Metrik vergleichen lassen und fragst deine Teams, ob es für sie in Ordnung ist, dass sie verglichen werden.

Teams können über die Story Point Metrik vergleichen lassen und zeigst es deinem Management

Du erwiderst, dass es bisher gibt es keine passende Metrik, weshalb du mit deinen Teams eine gemeinsame Retrospektive durchführst um eine zu finden

Du bemerkst im Daily, dass die Developer nicht an die Priorisierung des Product Owners glauben und stattdessen andere Aufgaben zuerst bearbeiten. Wie verhälst du dich?

Du beobachtest das Team im Daily und hinterfragst die Entscheidungen des Teams während dessen. Im Zweifel holst du den Product Owner dazu, um ein neue Übereinkunft zu finden.

Du lässt das Daily laufen und sprichst am Ende des Sprints in der Retrospektive an und lässt das Team das intern klären.

Du unterbrichst das Daily und lässt die Developer die richtigen Aufgaben ziehen. Im Zweifel holst du den Product Owner als Bestätigung dazu.

Du holst den Product Owner und das Management dazu und erklärst dem Developern wie wichtig es ist nach den Prioriäten zu arbeiten.

Welche Rolle gibt es in Scrum, damit es im Senior Management der Organisation representiert wird?

Die Rolle Scrum Master

Es gibt keine solche Rolle in Scrum

Die Rolle Stakeholder

Die Rolle Product Owner

Was sollten Developer unternehmen, wenn es mitten im Sprint feststellt, dass sie sich überplant haben und ihr Sprint Ziel nicht erreichen können?

Sie sollten sich mit dem Product Owner zusammen setzen, ausarbeiten was wirklich möglich ist und die Planung anpassen.

Sie sollten die Stakeholder fragen, was diese im kommende Sprint Review sehen wollen und die anderen Dinge einfach weglassen.

Sie sollten einfach weiterarbeiten, schließlich ist ein Sprint geschützt und darf nicht geändert werden.

Sie sollten den Scrum Master fragen, ob Sie die Aufgaben einfach mit in den nächsten Sprint nehmen dürfen.

Wie lange dauert eine Sprint Retrospective maximal?

45 min/ Sprint Woche (Timebox)

2h/ Sprint Woche(Timebox)

4h/ Sprint Woche(Timebox)

8h/ Sprint Woche (Timebox)

In der Sprint Retrospective will das Scrum Team von dir als Scrum Master eine Lösung für ihr Problem hören. Wie reagierst du?

Du hilfst aktiv dabei das Problem zu lösen und unterstützt sie dabei im laufenden Sprint.

Du lehnst es ab, da du keine Ahnung von dem Problem hast und nicht helfen kannst.

Du lehnst es ab, das Team selbstorgansiert und eigentverantwortlich handeln muss.

Du hilfst ihnen dabei, das Problem zu verstehen, unterstützt sie bei der Lösungsfindung, die Umsetzung liegt jedoch im Team

Welche Aussage trifft zum Product Backlog zu?

Das Product Backlog ist eine dynamische, emergente und priorisierte Liste die alle Produktanforderungen des Managements enthalten

Das Product Backlog beinhaltet alle Aufgaben die Developer im Sprint erledigen muss

Das Product Backlog ist eine dynamische, emergente und priorisierte Liste aller bekannten Anforderungen an das zu entwickelnde Produkt

Das Product Backlog beinhaltet die Anforderungen, welche Developer in der vorgegeben Zeit erledigen müssen

Du bist schon länger Scrum Master für zwei Teams im Unternehmen. Das Management will, dass du zwei neue Teams übernimmst du die anderen der Selbstorganisation überlässt, da es keine Ressourcen für mehr Scrum Master gibt. Wie reagierst du?

Du akzeptierst, dein Team soll sich jedoch die Rolle des Scrum Master aufteilen, da sie einen hohen Grad an Selbstorganisation aufweisen.

Du akzeptierst, da deine Teams bereits einen hohen Grad an Selbstorganisation aufweisen und auch alleine klar kommen.

Du akzeptierst, da du keine vier Teams als Scrum Master unterstützten kannst und du wirklich zuversichtlich bist, gelegntlich auch Zeit für diese Teams zu finden.

Du erklärst dem Management, dass ein Team ohne Scrum Master oder viele Teams mit einem Scrum Master erheblich an Wirkung verliert und nach einer anderen Lösung gesucht werden muss.

Was beschreibt ein Scrum Team am besten?

Ein crossfunktionales Team aus Developer, Scrum Master und Product Owner, welches in der Lage ein Produkt alleine zu entwickeln

Ein crossfunktionales Team, welches Scrum Master und Product Owner als Rollen etabliert haben

Ein crossfunktionales Team, welches in Sprints arbeitet und einen priorisierten Product Backlog pflegt.

Ein crossfunktionales Team, welches aus Developer, Scrum Master und Product Owner, welches Scrum erfolgreich umgesetzt hat

Was beinhaltet ein Product Backlog?

Eine priorisierte Liste aller Aufgaben, welche die Developer erledigen müssen

Eine priorisierte Liste aller Anforderungen und Features, welche den wahrscheinlichen Zielzustand des Produktes beschreiben

Eine priorisierte Liste aller Anforderungen und Features welche das Product am Ende haben muss

Eine priorisierte Liste der Stakeholder, wie das Produkt vom Scrum Team zu entwickeln ist

Du bist dabei ein neues Scrum Team aufzusetzen. Team Größe ist zu groß, wie reagierst du?

Du empfiehlst das sich die Developer in zwei interdisziplinäre Teams aufteilen sollten oder die größe auf die entsprechende Anzahl reduzieren sollen. Das Management muss dabei entscheiden.

Du hast auch schon mit größeren Teams gearbeitet also 9 Developer, daher lässt du es zu, planst aber direkt mit längeren Zeiten bei den Events, da mehr Teilnehmer dabei sind.

Du empfiehlst das sich die Developer in zwei interdisziplinäre Teams aufteilen sollten oder die größe auf die entsprechende Anzahl reduzieren sollen. Das Team muss dabei selbst entscheiden

Du hast auch schon mit größeren Teams gearbeitet also 9 Developer, daher lässt du es zu, warnst aber davor, dass die Effizienz nicht so gut sein wird.

Sollte ein Product Owner gleichzeitig der Scrum Master eines Team sein?

Nein, da es ansonsten zu einen Rollenkonflikt kommen kann.

Ja, aber nur wenn es sich um einen erfahrenen Scrum Master oder Product Owner handelt.

Ja, dadurch können erhebliche Personalkosten gespart werden

Nein, der Scrum Guide verbietet die Wahrnehmung von zwei Rollen durch eine Person

Was beschreibt Scrum am besten?

Eine Prozessbeschreibung wie innovative Produkte entwickelt werden können.

Ein Framework, welches sich bei der Entwicklung von Software bewährt hat

Eine Prozessbeschreibung wie agile Arbeitsweisen gelebt werden können

Ein Framework welches die Entwicklung innovativer Produkte unterstützt

Was beschreibt ein Commitment im Kontext von Scrum am Besten?

Commitment steht für eine Verpflichtung. Als ein agiles Framework braucht Scrum keine Commitments, da es die Agilität verhindert.

Commitment steht für eine Verpflichtung. Jedes Event hat ein Commitment, welches die korrekte Durchführung des Events fördert

Commitment steht für eine Verpflichtung. Jede Rolle beinhaltet ein Commitment, welches dazu verpflichtet die Rolle entsprechend des Scrum Guides durchzuführen

Commitment steht für eine Verpflichtung. Jedes Artefakt hat ein Commitment, welches die Transparent fördert und gegen den der Fortschritt gemessen werden kann

Welche Aussage trifft auf Scrum zu?

Scrum ist ein leichtgewichtiges Rahmenwerk, welches am besten durch einen Scrum Master angewendet wird.

Scrum ist ein leichtgewichtiges Rahmenwerk, welches den Entwicklungsprozess mit "good practices" unterstützt

Scrum ist eine Arbeitsempfehlung für agile Teams, um den klassischen Wasserfallprozess zu vermeiden

Scrum ist eine detailierte Anleitung wie Entwicklungen durchgeführt und verbessert werden

Was verantwortet ein Scrum Team? Wähle die passenste Aussage

Anforderungen entsprechend der Wunschliste der Stakeholder entwickeln

Ein innovatives Produkt markt- und Kundentauglich entwickeln

Meilenstein Reporting an das Management Team

Selbstorganisiert entscheiden, welches Produkt entwickelt werden soll.

Was macht eine gute User Story aus?

Eine gute User Story erzählt eine unterhaltsame Geschichte über den Nutzer des Produktes

Eine gute User Story enthält alle Notwendigen Anforderungen zur Entwicklung

Eine Gute User Story muss wie folgt geschrieben werden: Als Kunde will ich, ...

Eine gute User Story unterstützt das Scrum Team bei der Kommunikation zwischen Anforderungen und Lösungsfindung.

Eines deiner Teammitglieder hat bedenken ,dass durch agiles Arbeiten das Wissen in den bestehenden Prozesse nicht mehr genutzt wird. Welche Antwort solltest du in deiner Rolle aus Scrum Master geben?

Das Team braucht keine bestehenden Prozesse, da individuelle Abläufe ein Erfolgsgarant innovativer Produkte sind.

Das Team braucht keine bestehende Prozesse, da diese innovative Ideen des Teams unterdrücken

Das Team nutzt weiterhin auf bestehende Prozesse, sollte jedoch das Management vorher um erlaubnis fragen.

Das Team nutzt weiterhin bestehende Prozesse, sollte diese jedoch den Nutzen kritisch hinterfragen

Was ist richtig, wenn mehrere Teams an einem Produkt arbeiten sollen?

Für ein Produkt gibt es einen Product Backlog aber mehrere Product Owner

Für ein Produkt gibt es mehrere Product Backlogs, aber und einen Product Owner.

Für ein Produkt kann es mehrere Product Backlogs und mehrere Product Owner geben

Für ein Produkt gibt es einen Product Backlog und einen Product Owner.

Wann wird das Sprint Backlog aktualisiert?

Im Sprint Planning

Im Sprint Review

Im Daily Stand Up

Sobald eine Aufgabe fertig ist

Das Sprint Review wird in den ersten 15 min vom Product Owner genutzt um das Increment abzunehmen. Das Increment ist nahezu vollständig wie in den Akzeptanzkriterien beschrieben. Wie reagierst du als Scrum Master?

Du achtest auf das Feedback der Stakeholder und wartest bis nach dem Sprint Review und sprichst folgendes in der Retrospektive an: Eine Abnahme eines Increments sollte vor dem Sprint Review erfolgen, wenn ein Item als "Done" vom Team markiert wurde. Der Product Owner entscheidet ob es trotzdem im Sprint Review gezeigt werden kann.

Du wartest bis nach der Abnahme und lobst das Team vor den Stakeholdern für die gelungen Arbeit und unterstützt das Team beim Feedback durch die Stakeholder. Im Anschluss hilfst in der Retrospektive herauszufinden, wie das Produkt noch besser werden kann.

Du wartest bis zur Retrospective und gratulierst dem Team dazu, dass sie es fast geschafft haben ein vollständiges Increment abzuliefern. Danach versuchst mit ihnen herauszufinden, was zu einem vollständigen Increment gefehlt hat und wie ihr es im nächsten Sprint schaffen könnt.

Das Management will wissen, ob der Releasetermin gegenüber dem Kunden gehalten und taucht in Dailies auf um dem Team bei der fertigstellung von Aufgaben aktiv zu unterstützen. Wie reagierst du?

Du lässt sie nicht zuschauen, jedoch soll es einen Fortschrittsbericht nach jedem Daily geben der an das Management geschickt werden kann.

Du lässt sie nicht zuschauen und erklärst Ihnen, dass sie im Sprint Review teilnehmen können oder den Product Owner bezüglich des Produktfortschritts fragen können.

Du lässt sie zuschauen, sie dürfen aber nicht aktiv am Daily teilnehmen, da es die Selbstorganisation untergräbt.

Du lässt sie zuschauen und wenn das Team Unterstützung braucht, können Sie dem Team aktiv unter die Arme greifen.

Du bemerkst im Sprint Review, dass nur spärliches Feedback zum Sprint Review kommt. Was ist ein erster sinnvoller Schritt zur Verbesserung?

Du überlegst dir mit dem Team wie ihr das Sprint Review interaktiver gestalten könnt, damit die Stakeholder mehr Feedback geben können.

Gemeinsam mit dem Team nehmt ihr in der Retrospektive euer Sprint Review, das gezeigte Increment und die Stakeholder Besetzung unter die Lupe.

Du erklärst den Stakeholdern im nächsten Sprint Review wie wichtig, dass Feedback zum Produktfortschritt des Teams ist und bittest Sie sich mehr zu beteiligen.

Du zeigst den Developer wie sie ein besseres Increment erzeugen können, damit die Stakeholder mehr mit den Developer interagieren können.

Während des Sprints, äußern Stakholder bedenken bezüglich des Sprintziels gegenüber der Developer. Wie reagierst du als Scrum Master?

Du erklärst den Developer, dass sie die Stakeholder ignorieren sollen, das sie nicht in den Scrum Prozess eingreifen sollen.

Du erklärst den Stakeholdern, dass sie ihre bedenken gegenüber dem Product Owner äußern können, aber die Developer nicht von ihrer Arbeit abhalten sollen.

Du hilfst den Developer die Bedenken auszuräumen und die Stakeholder zufrieden zustellen.

Du erklärst den Stakeholdern, dass sie nicht in den Scrum Prozess eingreifen dürfen und bis zum Sprint Review arbeiten warten sollen.

Sowohl der Product Owner als Scrum Master dürfen die Developer bei der Entwicklungsarbeit unterstützen...

Ja, wenn es dem Produktfortschritt dient.

Nein, da der Scrum Guide es verbietet

Nein, da das dem Team längerfristig schadet

Ja, da der Scrum Guide es nicht verbietet

Wer gibt das Commitment für das Sprint Goal ab?

Die Developer

Der Scrum Master

Das Scrum Team

Wie kann ein Scrum Team mit nicht-funktionalen Features umgehen?

Nicht-Funktionale Features sind für das Produkt relevant und sollten deshalb vom Scrum Team regelmäßig mit funktionalen Features im Sprint umgsetzt werden

Nicht-Funktionale Features sind für das Produkt relevant und sollten aber von einem anderen Scrum Team umgesetzt werden

Nicht-Funktionale Features sind für das Produkt relevant und sollten deshalb vom Scrum Team in einem eigenen Sprint umgesetzt werden

Nicht-Funktionale Features sind für ein Scrum Team nicht relevant und sollten deshalbiert ignoriert werden

Was ist mit der zweiten Aussage des agilen Manifestes [Wir schätzen]… "Funktionierende Software (Produkte) mehr als umfassende Dokumentation" gemeint: Wähle die beste Antwort

Dokumentiere so viel wie nötig aber so wenig wie möglich

Software sollte Fehlerfrei an den Kunden geliefert werden

Fehlerfreie Software braucht keine Dokumentation

Dokumentation ist überflüssig und wird nicht benötigt

Welche Aussage trifft auf das Scrum Team zu?

Ein Scrum Team organisiert sich selbst und ist gesamtheitlich für den Produkterfolg verantwortlich

Ein Scrum Team organisiert sich selbst und kann sich daher auch selbst in der Retrospective auflösen

Ein Scrum Team organisiert sich selbst und ist für die Umsetzung des Sprint Backlogs verantwortlich

Ein Scrum Team organisert sich nicht selbst und wird vom Management in der Organisation unterstützt

Was ist eine Aussage des agilen Manifestes?

Individuen und Interaktionen vor umfassender Dokumentation

Individuen und Interaktionen vor Prozessen und Werkzeugen

Individuen und Interaktionen vor Vertragsverhandlungen

Individuen und Interaktionen vor dem befolgen eines Plans

Du hast die Aufgabe als Scrum Master aus 12 Personen ein Scrum Team zu formen. Was machst du?

Du informierst das Management, dass ihr eine Person nicht benötigt und setzt dann das Scrum Team aus 11 Perosnen zusammen

Du setzt dich mit den Personen zusammen und bildest ein interdisziplinäres Scrum Team

Du setzt dich mit den Personen zusammen und hilfst ihnen dabei sich selbst in mehrere Teams aufzuteilen

Du informierst das Management, dass sie genehmigen sollen, ein Scrum Team mit 12 Personen aufzusetzen.

Wer ist verantwortlich für den Produkterfolg in Scrum?

Der Product Owner

Das Scrum Team

Die Stakeholder

Der Scrum Master

Du bist verantwortlich für die Einführung von Scrum in einem Unternehmen. Was ist zu beachten, wenn du ein neues Scrum Team aufsetzt?

Du solltest ein interdisziplinäres Team zusammensetzen und das Management mit einem U-Boot Projekt davon überzeugen, dass Scrum funktioniert.

Du solltest ein freiwilliges interdisziplinäres Team finden, welche Scrum bereits kennen, das Management vorab zu Scrum schulen und eine lösbare Herausforderung für das Team finden.

Du solltest ein freiwilliges interdisziplinäres Team finden, welches die Unterstützung des Management hat und an einer für das Unternehmen wichtigen und komplexen Herausforderung alleine arbeiten kann.

Du solltest mit dem Management einen Workshop zu Scrum machen und sie dann ein Team für eine wichtige Herausforderung bestimmen lassen.

Eines deiner Scrum Teams, hat beschlossen die Sprint Retrospective nur noch alle zwei Sprints zu machen, da Sie nichts mehr haben worüber sie sprechen können. Wie reagierst du?

Du beobachtest dein Scrum Team ganz genau und führst jetzt erst recht eine Retrospektive durch und versuchst den wahren Grund für den Mangel an Themen herauszufinden.

Du versuchst dein Team von dem Mehrwert einer Retrospektive zu überzeugen in dem du eine Schulung zu dazu machst.

Du gestaltest das nächste Daily um machst direkt eine Retrospektive um herauszufinden warum es zu dieser Entscheidung kam.

Da dein Team selbstorganisiert ist akzeptierst du diese Entscheidung und befürwortest die Steigerung der verfügbaren Entwicklungszeit.

Was ist eine Aussage des agilen Manifestes?

Reagieren auf Veränderung vor Prozessen und Werkzeugen

Reagieren auf Veränderung vor dem befolgen eines Plans

Reagieren auf Veränderung vor umfassender Dokumentation

Reagieren auf Veränderung vor Vertragsverhandlungen

Für was sind die Developer im besonderen verantwortlich? Wähle die passenste Aussage

Eigenverantwortliche Umsetzung von Product Backlog Items in ein vom Kunden nutzbares Increment

Erstellen, Priorisierung und Umsetzung des Product Backlogs

Entwicklung einer Lösung, jedoch keine Test und Validierungsaufgaben

Qualitätsichernde Aufgaben für andere Produkte

Wer ist für das Product Backlog in Scrum verantwortlich?

Die Stakeholder

Der Scrum Master

Der Product Owner

Die Developer

Für was ist der Scrum Master im besonderen verantwortlich? Wähle die passenste Aussage

Weiterentwicklung des Teams zur Steigerung der Selbstorganisation

Lösen fachlicher Herausforderungen der Developer

Organisatorische Unterstützung des Team zur Steigerung der Effizienz

Moderations aller Scrum Events in einem Sprint

Time is Up!