05 Quiz: Scrum Grundlagen
January 2026 (2707 Words, 16 Minutes)
Neu: Interaktives Quiz verfügbar!
Möchtest du deinen Fortschritt verfolgen und sofortiges Feedback erhalten? Probiere unsere neue interaktive Version mit Fortschrittsverfolgung, sofortigen Erklärungen und Punkteberechnung.
Anleitung
- Dieses Quiz testet dein Verständnis von Scrum aus Kapitel 05 (Agile Entwicklung)
- Jede Frage hat 4 Optionen mit genau einer richtigen Antwort
- Konzentriere dich auf das Verständnis des WARUM hinter Scrum, nicht nur auf das Auswendiglernen von Begriffen
- Abschnitte: Rollen, Board-Analyse, V-Modell vs Agile, Sprint-Events
Abschnitt 1: Scrum-Rollen
Frage 1: Verantwortung des Product Owners
Ein Kunde wendet sich während eines Sprints an das Team und sagt “Ich brauche dieses neue Feature sofort!” Wer sollte auf diese Anfrage reagieren?
A) Der Scrum Master sollte es zum Sprint hinzufügen, da er das Team managt B) Das Development Team sollte es schätzen und hinzufügen, wenn sie Kapazität haben C) Der Product Owner sollte die Priorität bewerten und entscheiden, ob es den Sprint wert ist zu unterbrechen D) Der Kunde sollte bis zur Retrospektive warten, um neue Features anzusprechen
Antwort anzeigen
Richtige Antwort: C
Der Product Owner besitzt das Product Backlog und ist die einzige Stimme für die Priorisierung. Er entscheidet, WAS gebaut wird und in welcher Reihenfolge. Wenn ein neues Feature wirklich dringend ist, könnte der PO mit dem Team verhandeln, es gegen bestehende Sprint-Arbeit auszutauschen, aber diese Entscheidung gehört dem PO - nicht dem SM (der den Prozess handhabt) oder dem Team (das entscheidet, WIE gebaut wird).
Frage 2: Rolle des Scrum Masters
Das Development Team ist seit zwei Tagen blockiert, weil sie Zugang zu einem Produktionsserver benötigen, aber die IT-Abteilung hat auf ihre Anfrage nicht geantwortet. Wer sollte dies eskalieren?
A) Der Product Owner, da er die Geschäftsinteressen vertritt B) Der Scrum Master, da das Beseitigen von Impediments seine Verantwortung ist C) Der erfahrenste Entwickler, da es ein technisches Problem ist D) Niemand - das Team sollte geduldig warten und an anderen Aufgaben arbeiten
Antwort anzeigen
Richtige Antwort: B
Das Beseitigen von Impediments ist eine Kernverantwortung des Scrum Masters. Wenn das Team durch etwas außerhalb ihrer Kontrolle blockiert ist (wie IT-Zugang, Bürokratie oder organisatorische Probleme), eskaliert und löst der SM es. Der SM agiert als “Servant-Leader”, der das Team vor Ablenkungen schützt und Hindernisse beseitigt, damit sie sich auf die Lieferung konzentrieren können.
Frage 3: Technische Entscheidungen
Das Team debattiert, ob React oder Vue.js für das Frontend verwendet werden soll. Es gibt gültige Argumente für beides. Wer trifft die endgültige Entscheidung?
A) Der Product Owner, da er entscheidet, was gebaut wird B) Der Scrum Master, da er Teamentscheidungen moderiert C) Das Development Team, da technische Entscheidungen ihr Bereich sind D) Die Stakeholder, da sie das Endprodukt nutzen werden
Antwort anzeigen
Richtige Antwort: C
Das Development Team entscheidet, WIE Dinge gebaut werden. Technische Entscheidungen wie Frameworks, Architektur und Implementierungsdetails gehören den Leuten, die die Arbeit machen. Der PO entscheidet, WAS gebaut wird (Features, Prioritäten), aber nicht WIE. Der SM moderiert, aber trifft keine Entscheidungen für das Team.
Frage 4: Sprint-Demo
Beim Sprint Review demonstriert das Team ein Feature, das funktioniert, aber nicht ganz den Erwartungen der Stakeholder entspricht. Wer hat die Autorität, diese Arbeit anzunehmen oder abzulehnen?
A) Der Scrum Master, da er Qualität sicherstellt B) Das Development Team, da sie es gebaut haben C) Der Product Owner, da er die Stakeholder-Interessen vertritt D) Die Stakeholder direkt, da sie die Endbenutzer sind
Antwort anzeigen
Richtige Antwort: C
Der Product Owner akzeptiert oder lehnt abgeschlossene Arbeit ab, basierend darauf, ob sie die Definition of Done und die Akzeptanzkriterien erfüllt. Während Stakeholder-Feedback wertvoll ist (und beim Sprint Review gesammelt wird), ist der PO der einzige Entscheidungsträger, um widersprüchliche Anweisungen zu vermeiden. Wenn Stakeholder nicht einverstanden sind, verhandeln sie mit dem PO, nicht direkt mit dem Team.
Frage 5: Aufgabenzuweisung
Während des Sprint Planning sagt der Product Owner “Ich möchte, dass Entwickler A an der Datenbankaufgabe arbeitet, weil er der Experte ist.” Ist das angemessen?
A) Ja, der PO sollte sicherstellen, dass die richtigen Leute an den richtigen Aufgaben arbeiten B) Nein, der PO entscheidet, WAS gebaut wird, nicht WER es baut oder WIE C) Ja, aber nur wenn der Scrum Master die Zuweisung genehmigt D) Nein, nur der Scrum Master kann Aufgaben an Teammitglieder zuweisen
Antwort anzeigen
Richtige Antwort: B
In Scrum wird Arbeit von Teammitgliedern GEZOGEN, nicht von irgendjemandem ZUGEWIESEN. Das Development Team organisiert sich selbst, um zu entscheiden, wer an was arbeitet. Die Rolle des PO ist es, das Backlog zu priorisieren (WAS), nicht das Team zu managen (WIE/WER). Auch der Scrum Master weist keine Aufgaben zu - er beseitigt Impediments und coacht das Team in Scrum-Praktiken.
Frage 6: Scrum Master als Manager
Ein neuer Scrum Master beginnt zu verfolgen, wie viele Aufgaben jeder Entwickler pro Tag abschließt und verwendet diese Daten in seinen Leistungsbeurteilungen. Was ist falsch an diesem Ansatz?
A) Nichts - das sind gute Daten für kontinuierliche Verbesserung B) Der Scrum Master sollte nicht als Manager agieren oder individuelle Leistung bewerten C) Die Daten sollten Story Points enthalten, nicht nur Aufgabenzahlen D) Leistungsbeurteilungen sollten nur während Retrospektiven stattfinden
Antwort anzeigen
Richtige Antwort: B
Der Scrum Master ist KEIN Manager. Die Verwendung von Aufgabenzahlen für Leistungsbeurteilungen schafft individuellen Wettbewerb, der der Teamzusammenarbeit schadet. In Scrum ist das Team als Ganzes erfolgreich oder scheitert - es gibt kein “meine Aufgaben” vs “deine Aufgaben.” Der SM moderiert den Prozess und beseitigt Impediments; er managt keine Leute und bewertet keine Leistung.
Frage 7: Rollenüberschneidung
In einem kleinen Team von 4 Personen, kann eine Person sowohl Product Owner als auch Developer sein?
A) Ja, das ist üblich und völlig akzeptabel in Scrum B) Nein, der PO muss eine dedizierte Rolle getrennt vom Team sein C) Es ist möglich, aber schafft einen Interessenkonflikt zwischen WAS und WIE D) Nur wenn der Scrum Master die Doppelrolle genehmigt
Antwort anzeigen
Richtige Antwort: C
Während kleine Teams manchmal aus Notwendigkeit Rollen kombinieren, schafft es Spannungen, wenn eine Person sowohl PO als auch Developer ist. Als PO möchtest du vielleicht Feature X zuerst; als Developer würdest du vielleicht lieber an Feature Y arbeiten, weil es technisch interessanter ist. Die Trennung existiert, um Objektivität bei der Priorisierung zu wahren. Wenn du Rollen kombinieren musst, sei dir dieses Konflikts bewusst.
Abschnitt 2: Das Scrum Board
Frage 8: Board-Zustandsanalyse
Du schaust auf das Scrum Board des Teams und siehst: 0 Elemente in “To Do”, 8 Elemente in “In Progress”, 1 Element in “Review”, 0 Elemente in “Done”. Der Sprint ist zu 50% abgeschlossen. Was zeigt das an?
A) Das Team arbeitet sehr effizient an vielen Dingen gleichzeitig B) Zu viel Work in Progress (WIP) - das Team verteilt sich zu dünn C) Das Team braucht mehr Elemente in ihrem Sprint Backlog D) Dies ist ein gesunder Board-Zustand, der gute Parallelisierung zeigt
Antwort anzeigen
Richtige Antwort: B
8 Elemente in Bearbeitung zu haben mit keinem fertig zur Halbzeit ist ein klassisches “zu viel WIP”-Problem. Wenn Leute an zu vielen Dingen gleichzeitig arbeiten, schadet Kontext-Wechsel der Produktivität und nichts wird fertig. Ein gesundes Muster ist: weniger Dinge anfangen, beenden was du angefangen hast, dann mehr Arbeit ziehen. Das Board sollte von links nach rechts fließen, sich nicht in der Mitte anstauen.
Frage 9: Stagniertes Board
Das Scrum Board hat sich seit 3 Tagen nicht verändert. Die Daily Scrum Diskussionen sind kurz mit “arbeite immer noch am selben” von allen. Was passiert wahrscheinlich?
A) Das Team ist in einem produktiven “Flow-Zustand” und sollte nicht unterbrochen werden B) Es gibt versteckte Blocker, die nicht aufgedeckt oder adressiert werden C) Der Sprint war gut geplant und alles ist auf Kurs D) Das Team braucht das Board nicht, da sie gut kommunizieren
Antwort anzeigen
Richtige Antwort: B
Ein stagniertes Board zeigt normalerweise versteckte Probleme an. Wenn sich in 3 Tagen nichts bewegt hat, sind Aufgaben entweder blockiert (und niemand eskaliert), schlecht definiert (und Leute drehen sich im Kreis), oder das Team aktualisiert das Board nicht. Das Daily Scrum sollte diese Probleme aufdecken - “Ich stecke bei X fest wegen Y” - damit der SM helfen kann, sie zu lösen.
Frage 10: Board-Eigentum
Während des Sprints sieht der Product Owner, dass ein hochprioritäres Element immer noch in “To Do” ist und verschiebt es selbst nach “In Progress”, wobei er es einem bestimmten Entwickler zuweist. Was ist falsch an dieser Aktion?
A) Der PO hätte zuerst den Scrum Master fragen sollen B) Der PO hat Rollengrenzen verletzt - das Team besitzt das Board und zieht seine eigene Arbeit C) Nichts ist falsch; der PO stellt sicher, dass Prioritäten respektiert werden D) Der PO hätte es nach “In Review” verschieben sollen
Antwort anzeigen
Richtige Antwort: B
Das Development Team besitzt das Sprint Backlog und entscheidet, wie die Arbeit ausgeführt wird. Der PO hat Prioritäten während des Sprint Planning gesetzt; während des Sprints sollte er das Board nicht mikromanagen. Wenn der PO über den Fortschritt besorgt ist, sollte er es beim Daily Scrum oder mit dem SM ansprechen, nicht direkt Karten verschieben oder Arbeit zuweisen.
Frage 11: Warum Boards wichtig sind
Ein Team argumentiert, dass sie kein physisches oder digitales Board brauchen, weil sie gute Kommunikation haben und jeder weiß, woran alle anderen arbeiten. Was ist das Hauptrisiko, das Board zu überspringen?
A) Sie werden ihre Scrum-Zertifizierungsanforderungen nicht erfüllen B) Sie verlieren Transparenz - versteckte Annahmen über den Status führen zu Überraschungen C) Der Scrum Master wird nichts zu tun haben D) Sie werden ohne visuelle Motivation langsamer arbeiten
Antwort anzeigen
Richtige Antwort: B
Das Board ist ein “Informationsstrahler” - es macht Arbeit für alle sichtbar, ohne fragen zu müssen. Ohne es verlässt du dich auf jedermanns Gedächtnis und Annahmen, die mit der Zeit auseinanderdriften. “Ich dachte, du wärst damit fertig!” und “Ich wusste nicht, dass du blockiert bist!” werden häufig. Das Board ermöglicht Transparenz, eine der drei Säulen von Scrum (neben Inspektion und Anpassung).
Abschnitt 3: V-Modell vs. Agile
Frage 12: Problem mit spätem Feedback
Im V-Modell findet Testing nach Abschluss der Entwicklung statt. Was ist das Hauptproblem, das dies verursacht?
A) Testing dauert zu lange, weil Entwickler zu anderen Projekten weitergezogen sind B) Spät gefundene Defekte kosten 30-100x mehr zu beheben als früh gefundene Defekte C) Tester verstehen den Code nicht so gut wie Entwickler D) Die Testumgebung ist schwierig aufzusetzen
Antwort anzeigen
Richtige Antwort: B
Barry Boehms Forschung zeigte, dass die Kosten zur Behebung eines Defekts exponentiell steigen, wenn man durch die Entwicklungsphasen geht. Ein Requirements-Fehler, der während der Requirements-Phase gefunden wird, kostet 1x zu beheben; derselbe Fehler in der Produktion gefunden kostet 30-100x mehr. Die sequentiellen Phasen des V-Modells bedeuten, dass Probleme erst spät entdeckt werden, wenn sie am teuersten sind.
Frage 13: Requirements-Annahme
Das V-Modell nimmt an “wir können alle Requirements im Voraus kennen.” Warum ist diese Annahme problematisch?
A) Requirements-Dokumente brauchen zu lange zum Schreiben B) Stakeholder sind für Requirements-Erhebung nicht verfügbar C) Benutzer wissen nicht, was sie wollen, bis sie funktionierende Software sehen D) Requirements-Tools sind zu teuer für kleine Teams
Antwort anzeigen
Richtige Antwort: C
Dies verbindet sich mit Herbert Simons “begrenzte Rationalität” - Menschen können komplexe Systeme nicht vollständig vorhersagen. Benutzer wissen oft nicht, was sie brauchen, bis sie mit einem funktionierenden Prototyp interagieren. Das klassische Beispiel: “Ich sagte, ich wollte X, aber jetzt wo ich es sehe, erkenne ich, dass ich eigentlich Y brauche.” Agile umarmt dies, indem früh funktionierende Software geliefert und basierend auf Feedback iteriert wird.
Frage 14: Umgang mit Änderungen
Eine größere Requirement-Änderung tritt 6 Monate in ein 12-monatiges V-Modell-Projekt ein. Was passiert typischerweise?
A) Das Team passt die Änderung leicht an, da Requirements nur Dokumente sind B) Teure Nacharbeit: Spezifikationen, Designs und möglicherweise Code müssen alle aktualisiert werden C) Die Änderung wird abgelehnt, weil das Projekt zu weit fortgeschritten ist D) Nur die Testpläne müssen aktualisiert werden
Antwort anzeigen
Richtige Antwort: B
In einem sequentiellen Prozess kaskadiert eine Requirements-Änderung durch alle nachgelagerten Artefakte. Die Spezifikation muss sich ändern, was das Design ungültig macht, was Code-Änderungen erfordert, was neue Tests erfordert. Die Dokumentation jeder Phase muss überarbeitet werden. Agile minimiert dies, indem in kurzen Zyklen gearbeitet wird, wo “Änderung” nur das Repriorisieren des Backlogs ist - nicht das Neuschreiben von Monaten an Dokumentation.
Frage 15: Wann das V-Modell funktioniert
Trotz seiner Einschränkungen kann das V-Modell in einigen Kontexten immer noch angemessen sein. Welches Szenario könnte die Verwendung eines V-Modell-Ansatzes rechtfertigen?
A) Ein Startup, das eine neue mobile App mit häufigen Pivots baut B) Ein Medizinprodukt, das FDA-Zertifizierung mit obligatorischer Dokumentation erfordert C) Eine Webanwendung mit wöchentlichen Releases D) Ein internes Tool, bei dem sich Requirements monatlich ändern
Antwort anzeigen
Richtige Antwort: B
Regulierte Branchen (Medizin, Luftfahrt, Automobil-Sicherheit) erfordern oft umfangreiche Dokumentation für die Zertifizierung. Die explizite Phasen-zu-Test-Zuordnung des V-Modells bietet die Nachverfolgbarkeit, die Auditoren brauchen. Allerdings übernehmen auch diese Branchen agile Praktiken innerhalb regulatorischer Beschränkungen - das US-Army-Beispiel zeigt, dass “reguliert” nicht “muss Wasserfall verwenden” bedeutet.
Abschnitt 4: Sprint-Events
Frage 16: Sprint Planning Outputs
Was sind die ZWEI wichtigsten Outputs des Sprint Planning?
A) Aktualisiertes Product Backlog und Teamzuweisungen B) Sprint Backlog und Sprint Goal C) Testplan und Deployment-Zeitplan D) Technisches Design und Zeitschätzungen
Antwort anzeigen
Richtige Antwort: B
Sprint Planning produziert: (1) Das Sprint Backlog - die aus dem Product Backlog ausgewählten Elemente plus einen Plan für ihre Lieferung, und (2) Das Sprint Goal - eine kurze Aussage darüber, was der Sprint erreichen soll. Das Sprint Goal bietet Fokus und Flexibilität: wenn bestimmte Elemente nicht abgeschlossen werden können, könnte das Ziel trotzdem durch alternative Ansätze erreicht werden.
Frage 17: Zweck des Daily Scrum
Was ist der Hauptzweck des Daily Scrum (Standup)?
A) Fortschritt an den Scrum Master zu berichten B) Das Team zu synchronisieren und Blocker für die nächsten 24 Stunden zu identifizieren C) Aufgaben für den Tag zuzuweisen D) Das Burndown Chart zu aktualisieren
Antwort anzeigen
Richtige Antwort: B
Das Daily Scrum ist für das Development Team, um sich untereinander zu synchronisieren - nicht um jemandem zu berichten. Die klassischen drei Fragen (Was habe ich getan? Was werde ich tun? Was blockiert mich?) helfen zu identifizieren, wer Hilfe braucht, was feststeckt und wie koordiniert werden kann. Es ist kein Status-Report-Meeting - es ist ein Planungsmeeting für die nächsten 24 Stunden.
Frage 18: Sprint Review vs. Retrospektive
Was ist der Hauptunterschied zwischen Sprint Review und Sprint Retrospective?
A) Review ist für Entwickler; Retrospective schließt Stakeholder ein B) Review inspiziert das PRODUKT (was gebaut wurde); Retrospective inspiziert den PROZESS (wie wir gearbeitet haben) C) Review findet wöchentlich statt; Retrospective findet monatlich statt D) Review ist optional; Retrospective ist obligatorisch
Antwort anzeigen
Richtige Antwort: B
Das Sprint Review untersucht das Produkt - das Team demonstriert, was abgeschlossen wurde, Stakeholder geben Feedback, und das Product Backlog kann basierend auf Erkenntnissen aktualisiert werden. Die Sprint Retrospective untersucht den Prozess - was gut funktioniert hat, was nicht, und was im nächsten Sprint verbessert werden soll. Beide sind essenziell, haben aber unterschiedliche Fokuspunkte.
Frage 19: Sprint-Abbruch
Unter welchen Umständen kann ein Sprint vor seinem Enddatum abgebrochen werden?
A) Niemals - Sprints werden nie verlängert oder verkürzt B) Wenn der Product Owner feststellt, dass das Sprint Goal obsolet geworden ist C) Wenn das Team erkennt, dass sie nicht alle zugesagte Arbeit abschließen können D) Wenn ein kritischer Bug in der Produktion gefunden wird
Antwort anzeigen
Richtige Antwort: B
Nur der Product Owner kann einen Sprint abbrechen, und nur wenn das Sprint Goal obsolet wird (z.B. das Unternehmen pivotiert, der Markt ändert sich dramatisch). Sprint-Abbrüche sind selten und störend. Hinweis: unvollständige Arbeit ist KEIN Grund zum Abbruch - sie kehrt einfach zum Backlog zurück. Der Sprint endet trotzdem pünktlich, und das Team reflektiert, warum Arbeit nicht abgeschlossen wurde.
Frage 20: Retrospektive Action Items
Die Retrospektive des Teams identifiziert, dass “Code Reviews zu lange dauern und den Fortschritt blockieren.” Was sollte als nächstes passieren?
A) Der Scrum Master sollte kürzere Review-Zeiten anordnen B) Das Team sollte einen spezifischen Action Item hinzufügen, um dies im nächsten Sprint zu verbessern C) Dies sollte an das Management für eine Prozessänderung eskaliert werden D) Das Team sollte Code Reviews überspringen, um schneller zu sein
Antwort anzeigen
Richtige Antwort: B
Retrospektiven sollten konkrete, umsetzbare Verbesserungen produzieren. “Wir werden versuchen, Reviews zu pairen, um sie schneller zu machen” oder “Wir werden ein Review-SLA von 4 Stunden hinzufügen” sind gute Action Items. Das Team besitzt seinen Prozess und experimentiert mit Änderungen. Qualitätspraktiken zu überspringen (D) schafft technische Schulden; an das Management zu eskalieren (C) nimmt dem Team das Eigentum. Der SM ordnet keine Lösungen an (A) - er moderiert, dass das Team seine eigenen findet.
Zusammenfassung
Getestete Schlüsselkonzepte:
- Rollen: PO entscheidet WAS, Team entscheidet WIE, SM beseitigt Impediments
- Board: Transparenz ermöglicht Zusammenarbeit; achte auf WIP-Überlastung
- V-Modell vs. Agile: Spätes Feedback ist teuer; umarme Änderung durch kurze Zyklen
- Events: Jede Zeremonie hat einen spezifischen Zweck; überspringe sie nicht
Bereit für mehr? Wiederhole die Vorlesungsfolien und probiere die Sprint Game Übung!