Skip to content
Agile
Agile Practitioner
Agile Master
Agile Coach
Agile Leadership
Design Thinking
SCRUM
Kanban
OKR
About
Competency model
Experts
Partner
Blog
Agile Practitioner
Login / Register
0
No products in the cart.
0
Cart
No products in the cart.
Welcome to your Scrum Master German
Wann wird das Sprint Backlog aktualisiert?
Im Daily Stand Up
Im Sprint Planning
Im Sprint Review
Sobald eine Aufgabe fertig ist
Was sind die fünf Scrum Events?
Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Scrum Management Meeting
Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Sprintend Meeting
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 nutzt weiterhin auf bestehende Prozesse, sollte jedoch das Management vorher um erlaubnis fragen.
Das Team braucht keine bestehenden Prozesse, da individuelle Abläufe ein Erfolgsgarant innovativer Produkte sind.
Das Team nutzt weiterhin bestehende Prozesse, sollte diese jedoch den Nutzen kritisch hinterfragen
Das Team braucht keine bestehende Prozesse, da diese innovative Ideen des Teams unterdrücken
Wer gibt das Commitment für das Sprint Goal ab?
Der Scrum Master
Die Developer
Das Scrum Team
Die Developer
Welche Rolle gibt es in Scrum, damit es im Senior Management der Organisation representiert wird?
Es gibt keine solche Rolle in Scrum
Die Rolle Product Owner
Die Rolle Stakeholder
Die Rolle Scrum Master
Was ist zu beachten wenn es um die Definition of Done geht?
Die Definition of Done gilt für alle Backlog Items sichert die Qualität eines Increments ab.
Die Definition of Done beschreibt wann die Developer den Sprint abgeschlossen haben.
Die Definition of Done ist ein zentrales Dokument der Entwicklung und wird bei der Abnahme als Qualitätsmaßstab benutzt.
Die Definition of Done beschreibt, wann das Produkt "Done" ist und gilt daher über das gesamte Projekt.
Für was ist der Scrum Master im besonderen verantwortlich? Wähle die passenste Aussage
Weiterentwicklung des Teams zur Steigerung der Selbstorganisation
Organisatorische Unterstützung des Team zur Steigerung der Effizienz
Lösen fachlicher Herausforderungen der Developer
Moderations aller Scrum Events in einem Sprint
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 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.
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
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 deshalb vom Scrum Team in einem eigenen Sprint umgesetzt 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 ein Scrum Team nicht relevant und sollten deshalbiert ignoriert werden
Sowohl der Product Owner als Scrum Master dürfen die Developer bei der Entwicklungsarbeit unterstützen...
Nein, da der Scrum Guide es verbietet
Ja, wenn es dem Produktfortschritt dient.
Ja, da der Scrum Guide es nicht verbietet
Nein, da das dem Team längerfristig schadet
Welche Aussage trifft auf das Management in Scrum zu?
Das Management organisiert das Team und wird durch den Scrum Master repräsentiert
Das Management gibt wertvolles Feedback zum Scrum Prozess
Das Scrum Team hat kein Management. Es managet sich selbst.
Das Management gibt wertvolles Feedback zum Produktfortschritt
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 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 sich mit dem Product Owner zusammen setzen, ausarbeiten was wirklich möglich ist und die Planung anpassen.
Sie sollten den Scrum Master fragen, ob Sie die Aufgaben einfach mit in den nächsten Sprint nehmen dürfen.
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
Welche fünf Scrum Werte gibt es?
Transparenz, Inspektion, Anpassung, Fokus, Mut
Respekt, Mut, Commitment, Transparenz, Offenheit
Selbstorganisation, Eigenverantwortung, Priorisierung, Transparenz, Commitment
Mut, Respekt, Commitment, Fokus, Offenheit
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 holst den Product Owner und das Management dazu und erklärst dem Developern wie wichtig es ist nach den Prioriäten zu arbeiten.
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 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 unterbrichst das Daily und lässt die Developer die richtigen Aufgaben ziehen. Im Zweifel holst du den Product Owner als Bestätigung dazu.
Das Team plant im Sprint Planning den Sprint Backlog… Wie detailliert muss die Planung der Developer sein?
Die Developer planen die Aufgaben so, sie das Sprintziel realisitisch erreichen und den Arbeitsfortschritt verfolgen können
Die Developer planen so, dass jede Aufgabe einen Verantwortlichen hat und der Product Owner nachvollziehen kann, dass das Sprintziel erreicht wird
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 ordnen den Aufgaben Verantwortungen zu und planen sie dann selbstorgansieiert
Welche Aussage trifft zum Product Backlog zu?
Das Product Backlog beinhaltet die Anforderungen, welche Developer in der vorgegeben Zeit erledigen müssen
Das Product Backlog ist eine dynamische, emergente und priorisierte Liste aller bekannten Anforderungen an das zu entwickelnde Produkt
Das Product Backlog beinhaltet alle Aufgaben die Developer im Sprint erledigen muss
Das Product Backlog ist eine dynamische, emergente und priorisierte Liste die alle Produktanforderungen des Managements enthalten
Sollte ein Product Owner gleichzeitig der Scrum Master eines Team sein?
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
Nein, da es ansonsten zu einen Rollenkonflikt kommen kann.
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, 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 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 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.
Wer ist für die Erstellung des Product Goals verantwortlich?
Der Scrum Master
Die Stakeholder
Der Product Owner
Das Management Team
Was beschreibt ein Scrum Team am besten?
Ein crossfunktionales Team, welches in Sprints arbeitet und einen priorisierten Product Backlog pflegt.
Ein crossfunktionales Team, welches Scrum Master und Product Owner als Rollen etabliert haben
Ein crossfunktionales Team, welches aus Developer, Scrum Master und Product Owner, welches Scrum erfolgreich umgesetzt hat
Ein crossfunktionales Team aus Developer, Scrum Master und Product Owner, welches in der Lage ein Produkt alleine zu entwickeln
Du hast die Aufgabe als Scrum Master aus 12 Personen ein Scrum Team zu formen. Was machst du?
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 ihr eine Person nicht benötigt und setzt dann das Scrum Team aus 11 Perosnen zusammen
Du informierst das Management, dass sie genehmigen sollen, ein Scrum Team mit 12 Personen aufzusetzen.
Nach jedem Sprint muss es einen Release für den Kunden geben.
Richtig - Aber nur wenn der Kunde es im Sprint Planning bestellt hat
Falsch - Am Ende eines Sprint muss Increment ledegilich potenziell auslieferbar sein
Richtig - Regelmäßige Auslieferungen an den Kunden sind wichtig.
Falsch - Das Team kann jederzeit an den Kunden ausliefern
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 und wenn das Team Unterstützung braucht, können Sie dem Team aktiv unter die Arme greifen.
Du lässt sie zuschauen, sie dürfen aber nicht aktiv am Daily teilnehmen, da es die Selbstorganisation untergräbt.
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 versuchts herauszufinden, warum das Managementteam daran glaubt. Gemeinsam arbeitet ihr an einem Beispiel den Unterschied für das Managementteam erlebbar zu machen.
Du widersprichst und zeigst ihnen anhand von Praxis Beispielen aus deiner Erfahrung warum sie falsch liegen
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
Was ist eine gute Representation eines Cross-Funktionalen Teams?
Alle Entwickler die benötigt werden um die Funktionen zu entwickeln
Möglichst viele Entwickler aus einem Fachbereich.
Einen Scrum Master, Einen Product Owner und mindestens 3 Developer.
Alle Funtkionen, die zur Realisierung des Produktes benötigt werden
Wie sollen die Items im Sprint Backlog jeden einzelnem Teammitglied zugeordnet werden?
Nach dem Pullverfahren: Im Daily Stand Up ziehen sich die Developer die Aufgaben aus dem Sprint Backlog
Nach dem Push-Verfahren: Der Product Owner weist die Aufgaben im Sprint Planning zu
Nach dem Push-Verfahren: Der Scrum Master weist die Aufgaben im Daily Stand up zu
Nach dem Pullverfahren: Im Planning verteilen die Developer alle Aufgaben des Sprints
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 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.
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 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.
Was beinhaltet ein Product Backlog?
Eine priorisierte Liste aller Anforderungen und Features welche das Product am Ende haben muss
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 der Stakeholder, wie das Produkt vom Scrum Team zu entwickeln 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?
Der Stakeholder darf nach Zustimmung des Teams mit an den Dailys teilnehmen.
Wenn der Stakeholder stärker eingebunden werden möchte, muss er Teil der Developer werden und seine Stakeholder Rolle verlassen.
Du setzt dich mit dem Stakeholder zusammen und versuchst herauszufinden, was genau das Bedürfnis des Stakeholder ist.
Du nimmst den Stakeholder in Abstimmung mit dem Team als Experten mit ins Planning.
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 hilfst ihnen dabei, das Problem zu verstehen, unterstützt sie bei der Lösungsfindung, die Umsetzung liegt jedoch im Team
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 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.
Du erwiderst, dass es bisher gibt es keine passende Metrik, weshalb du mit deinen Teams eine gemeinsame Retrospektive durchführst um eine zu finden
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
Das Product Backlog ist das das selbe wie ein klassischer Projektplan nur bestehen die Arbeitspakete aus Stories...
Nein, ein Product Backlog beinhaltet einen priorisierte Liste der Anforderungen des Produktes
Nein, das Product Backlog besteht auch aus Epics, Features und Tasks und nicht nur 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
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 Stakeholdern, dass sie nicht in den Scrum Prozess eingreifen dürfen und bis zum Sprint Review arbeiten warten sollen.
Du erklärst den Developer, dass sie die Stakeholder ignorieren sollen, das sie nicht in den Scrum Prozess eingreifen sollen.
Du hilfst den Developer die Bedenken auszuräumen und die Stakeholder zufrieden zustellen.
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.
Welche Aussage trifft auf Stakeholder in Scrum zu?
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
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
Du bemerkst im Sprint Review, dass nur spärliches Feedback zum Sprint Review kommt. Was ist ein erster sinnvoller Schritt zur Verbesserung?
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 überlegst dir mit dem Team wie ihr das Sprint Review interaktiver gestalten könnt, damit die Stakeholder mehr Feedback geben können.
Du zeigst den Developer wie sie ein besseres Increment erzeugen können, damit die Stakeholder mehr mit den Developer interagieren können.
Gemeinsam mit dem Team nehmt ihr in der Retrospektive euer Sprint Review, das gezeigte Increment und die Stakeholder Besetzung unter die Lupe.
Was ist eine Aussage des agilen Manifestes?
Individuen und Interaktionen vor umfassender Dokumentation
Individuen und Interaktionen vor dem befolgen eines Plans
Individuen und Interaktionen vor Vertragsverhandlungen
Individuen und Interaktionen vor Prozessen und Werkzeugen
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
Software sollte Fehlerfrei an den Kunden geliefert werden
Dokumentiere so viel wie nötig aber so wenig wie möglich
Fehlerfreie Software braucht keine Dokumentation
Dokumentation ist überflüssig und wird nicht benötigt
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 nimmst dir den Product Owner direkt vor. Das Team soll schließlich selbstorganisert sein
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 übernimmst die Moderation vom Product Owner.
Du hälst das Daily an und bestimmst einen Developer für die Moderation. Das Team ist schließlich selbstorganisiert
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 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.
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.
Welche Aussage trifft auf Scrum zu?
Scrum ist ein leichtgewichtiges Rahmenwerk, welches den Entwicklungsprozess mit "good practices" unterstützt
Scrum ist eine detailierte Anleitung wie Entwicklungen durchgeführt und verbessert werden
Scrum ist eine Arbeitsempfehlung für agile Teams, um den klassischen Wasserfallprozess zu vermeiden
Scrum ist ein leichtgewichtiges Rahmenwerk, welches am besten durch einen Scrum Master angewendet wird.
Wer lädt die Stakeholder in das Sprint Review ein?
Die Developer
Der Product Owner
Der Scrum Master
Niemand, die Stakeholder kommen einfach
Was ist richtig, wenn mehrere Teams an einem Produkt arbeiten sollen?
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.
Für ein Produkt gibt es mehrere Product Backlogs, aber und einen Product Owner.
Für ein Produkt gibt es einen Product Backlog aber mehrere Product Owner
Welche Aussage trifft auf ein Backlog Item zu, welches als "Done" bezeichnet wird?
Wenn alle dazugehörigen geplanten Aufgaben als "Done" markiert sind und keine weiteren Aufgaben auf dem Board sind
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 der Scrum Master im Daily das Product Backlog Item abgenommen hat und es als "Done" deklariert
Für was sind die Developer im besonderen verantwortlich? Wähle die passenste Aussage
Erstellen, Priorisierung und Umsetzung des Product Backlogs
Eigenverantwortliche Umsetzung von Product Backlog Items in ein vom Kunden nutzbares Increment
Qualitätsichernde Aufgaben für andere Produkte
Entwicklung einer Lösung, jedoch keine Test und Validierungsaufgaben
Wie sollte eine optimale Sprint Planning vorbereitet werden?
Die Developer sollten das Sprintziel und die benötigten Backlog Items und dazugehörigen Aufgaben vorbereitet haben
Der Product Owner sollte einen Vorschlag für das Sprint Ziel und das Refinement der dafür benötigten Backlog Items sicherstellen
Der Scrum Master in Abstimmung mit dem Team, das Sprintziel, die Backlog Items und den Raum für das Planning vorbereitet haben
Das Scrum Team sollte das Product Backlog Refinment direkt vor dem Sprint Planning durchführen.
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 verweist auf die gemeinsame Vereinbarungen, welche zu Beginn des Projektes geschlossen wurde und bittest das Management das Team in Ruhe zu lassen
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
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 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.
Wie lange dauert eine Sprint Retrospective maximal?
4h/ Sprint Woche(Timebox)
45 min/ Sprint Woche (Timebox)
2h/ Sprint Woche(Timebox)
8h/ Sprint Woche (Timebox)
Als Product Owner verantwortest du den Product Backlog. Wie stellst du sicher, dass die richtigen Dinge durch das Team zuerst bearbeitet werden?
Im Daily Stand up kann ich die Developer auf die Prioriäten hinweisen, sodass sie nicht die falschen Aufgaben zuerst bearbeiten
Ich kann den Scrum Master im Daily überprüfen lassen, ob das Team auch an den richtigen Dingen arbeitet
Ich installiere ein Meeting pro Woche in dem ich mir den Arbeitsfortschritt zu wichtigsten Items zeigen lasse.
Im Sprint Planning kann ich meine Prioriäten gegenüber dem Team durch die zu bearbeiten Items und das Sprint Ziel klar darstellen.
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 versuchst dein Team von dem Mehrwert einer Retrospektive zu überzeugen in dem du eine Schulung zu dazu machst.
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.
Da dein Team selbstorganisiert ist akzeptierst du diese Entscheidung und befürwortest die Steigerung der verfügbaren Entwicklungszeit.
Du gestaltest das nächste Daily um machst direkt eine Retrospektive um herauszufinden warum es zu dieser Entscheidung kam.
Für was ist ein Product Owner verantwortlich? Wähle die passenste Aussage
Lösen von Impediments in der Retrospektive
Die Erstellung eines priorisierten Product Backlogs
Aufgabenverteilung an das Team im Sprint Planning
Priorisierung der Tasks für die Developer im Daily Stand-up
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 unterstützt das Scrum Team bei der Kommunikation zwischen Anforderungen und Lösungsfindung.
Eine Gute User Story muss wie folgt geschrieben werden: Als Kunde will ich, ...
Eine gute User Story enthält alle Notwendigen Anforderungen zur Entwicklung
Was ist eine Aussage des agilen Manifestes?
Reagieren auf Veränderung vor umfassender Dokumentation
Reagieren auf Veränderung vor Vertragsverhandlungen
Reagieren auf Veränderung vor Prozessen und Werkzeugen
Reagieren auf Veränderung vor dem befolgen eines Plans
Wer ist für das Product Backlog in Scrum verantwortlich?
Der Scrum Master
Die Stakeholder
Der Product Owner
Die Developer
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. Jede Rolle beinhaltet ein Commitment, welches dazu verpflichtet die Rolle entsprechend des Scrum Guides durchzuführen
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. Jedes Artefakt hat ein Commitment, welches die Transparent fördert und gegen den der Fortschritt gemessen werden kann
Was verantwortet ein Scrum Team? Wähle die passenste Aussage
Selbstorganisiert entscheiden, welches Produkt entwickelt werden soll.
Meilenstein Reporting an das Management Team
Ein innovatives Produkt markt- und Kundentauglich entwickeln
Anforderungen entsprechend der Wunschliste der Stakeholder entwickeln
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 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
Ein Scrum Team organisiert sich selbst und kann sich daher auch selbst in der Retrospective auflösen
Wann findet die Sprint Retrospective am Ende des Sprints statt?
Immer nach dem Sprint Planning, um die Planung auf Veränderung anzupassen.
Am Ende eines Sprints. hat das Team die Ruhe und Zeit um die Zusammenarbeit zu reflektieren
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.
Wer ist verantwortlich für den Produkterfolg in Scrum?
Die Stakeholder
Der Product Owner
Der Scrum Master
Das Scrum Team
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 mit dem Management einen Workshop zu Scrum machen und sie dann ein Team für eine wichtige Herausforderung bestimmen lassen.
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.
Time is Up!
Search for:
Agile
Agile Practitioner
Agile Master
Agile Coach
Agile Leadership
Design Thinking
SCRUM
Kanban
OKR
About
Competency model
Experts
Partner
Blog
Login
Login / Register