SM-Dienst [Praxis]

8 Übungsfragen mit Lösung und Erklärung.

✌️ MultiWie dient der Scrum Master dem Scrum-Team? (Mehrere richtig)
Das Team im Selbstmanagement und in Cross-Funktionalität coachen
Die Backlog-Reihenfolge festlegen
Die Aufgaben der Developers täglich zuweisen
Hindernisse zur Zielerreichung beseitigen helfen
Dafür sorgen, dass alle Scrum-Events stattfinden und produktiv sind
Der SM coacht Selbstmanagement/Cross-Funktionalität, hilft Hindernisse zu beseitigen und sorgt für wirksame Events. Aufgaben zuweisen (Developers) und Backlog ordnen (PO) sind nicht seine Aufgaben.
☝️ SingleDer Scrum Master dient laut Scrum Guide drei Adressaten. Welche sind das?
Dem Team, dem Management und den Kunden
Dem Scrum Team, dem Product Owner und der Organisation
Dem Product Owner, den Stakeholdern und der IT-Leitung
Den Developers, den Stakeholdern und dem Betriebsrat
Der Dienst richtet sich an das Scrum Team, den Product Owner und die Organisation als Ganzes.
✌️ MultiWie dient der Scrum Master der Organisation? (Mehrere richtig)
Indem er Projektstatusberichte für die Geschäftsleitung erstellt
Indem er die Personalbeurteilung der Developers übernimmt
Indem er Scrum-Einführungen anleitet und begleitet
Indem er Mitarbeitende und Stakeholder in empirischem Vorgehen schult
Indem er Barrieren zwischen Stakeholdern und Scrum Teams abbaut
Personalbeurteilung und Statusberichterstattung sind keine Aufgaben des Scrum Masters. Sie widersprechen der dienenden Führung.
✌️ MultiWie dient der Scrum Master dem Product Owner? (Mehrere richtig)
Er ordnet das Product Backlog, wenn der Product Owner keine Zeit hat
Er unterstützt bei klarer und prägnanter Formulierung von Backlog-Einträgen
Er hilft, empirische Produktplanung in einem komplexen Umfeld zu etablieren
Er entscheidet über Release-Termine
Er hilft, Techniken zur wirksamen Definition des Product Goals zu finden
Der Scrum Master unterstützt den Product Owner methodisch, übernimmt aber niemals dessen Entscheidungen.
✍️ OffenEin Scrum Master soll die Wirksamkeit seiner eigenen Arbeit belegen. Welche Anhaltspunkte sind aussagekräftig und welche nicht?
Musterantwort: Aussagekräftig sind Größen, die zeigen, ob das System besser funktioniert: Liefert das Team regelmäßig ein Increment, das die Definition of Done erfüllt? Wird die Definition of Done über die Zeit strenger statt schwächer? Nimmt die Zahl wiederkehrender Impediments ab, und werden sie schneller gelöst? Löst das Team Probleme zunehmend selbst, ohne den Scrum Master? Kommt echtes Stakeholder-Feedback im Review an und verändert es das Product Backlog? Setzt das Team Verbesserungen aus der Retrospektive tatsächlich um? Nicht aussagekräftig sind Velocity, Auslastung, Zahl moderierter Meetings, Anwesenheitsquoten oder die Einhaltung ursprünglicher Schätzungen. Diese Größen messen Aktivität statt Wirkung und erzeugen als Ziel eingesetzt Fehlanreize. Wichtig ist außerdem, dass die Anhaltspunkte gemeinsam mit dem Team betrachtet werden, statt sie als Berichtsinstrument nach oben zu verwenden.
Bewertet werden: Wirkungsgrößen (Increment/DoD-Entwicklung, Impediment-Verlauf, Selbstständigkeit, Feedbackwirkung, Umsetzung von Verbesserungen) + Abgrenzung untauglicher Aktivitätsgrößen (Velocity, Auslastung, Meetingzahl) + Hinweis auf Fehlanreize bzw. gemeinsame Betrachtung.
✍️ OffenEin Scrum Master soll drei Teams gleichzeitig betreuen und kommt kaum über die Moderation der Events hinaus. Analysieren Sie die Lage.
Musterantwort: Die Lage deutet darauf hin, dass die Rolle auf ihren sichtbarsten Teil reduziert wurde. Die Moderation der Events ist nur ein Ausschnitt der Verantwortung; hinzu kommen die Arbeit an Impediments außerhalb des Teams, die Unterstützung des Product Owners bei Backlog-Management und Produktplanung, die Entwicklung der Selbstverwaltung sowie die Arbeit an den organisatorischen Rahmenbedingungen. Genau diese Anteile fallen bei Überlast zuerst weg, weil sie keinen Kalendereintrag haben und ihr Ausbleiben nicht sofort auffällt. Die Folge ist ein Scrum Master, der als Meeting-Moderator wahrgenommen wird, während die eigentlichen Hindernisse unbearbeitet bleiben – und das wiederum bestätigt das Bild der Rolle als reiner Terminorganisation. Als Auswege kommen mehrere Ansätze in Betracht. Kurzfristig lässt sich die Moderation schrittweise an die Teams abgeben, was ohnehin dem Ziel der Selbstverwaltung entspricht, sodass Kapazität für die Themen frei wird, die nur er bearbeiten kann. Mittelfristig muss er die Überlastung gegenüber dem Management transparent machen, und zwar nicht als persönliche Klage, sondern anhand konkreter Folgen: liegengebliebene Impediments, wiederkehrende Probleme, verzögerte Entscheidungen. Möglich ist auch, sich bewusst auf weniger Teams zu konzentrieren, statt alle gleich schlecht zu begleiten. Entscheidend ist, die Frage nicht als Zeitmanagementproblem zu behandeln, sondern als Frage, welchen Anspruch die Organisation an die Rolle tatsächlich stellt.
☝️ SingleEin Scrum Master stellt fest, dass zwei Teams sich gegenseitig blockieren, weil beide auf dieselbe zentrale Komponente zugreifen. Beide Teams haben eigene Scrum Master. Wie geht er vor?
Er bittet den Product Owner, die Einträge so zu ordnen, dass keine Überschneidung entsteht
Er löst das Problem für sein Team und überlässt das andere Team sich selbst
Er eskaliert an die gemeinsame Führungskraft
Er bringt beide Teams und beide Scrum Master zusammen, damit die Abhängigkeit gemeinsam sichtbar gemacht und behandelt wird
Abhängigkeiten zwischen Teams sind ein klassisches organisationales Impediment und lassen sich einseitig nicht auflösen, sondern nur verlagern. Eskalation und Umsortierung des Backlogs sind Folgeoptionen, wenn die gemeinsame Bearbeitung nicht trägt.
☝️ SingleEin Team hat sich über zwei Jahre daran gewöhnt, dass der Scrum Master alle Impediments beseitigt. Er wechselt das Team. Welches Risiko ist am größten?
Das Team hat keine Praxis darin, Hindernisse selbst zu benennen und anzugehen, und wird handlungsunfähig, sobald niemand mehr einspringt
Die offenen Impediments gehen bei der Übergabe verloren
Die Velocity sinkt vorübergehend
Der neue Scrum Master kennt die Organisation nicht
Das ist die Kehrseite eines scheinbar sehr erfolgreichen Scrum Masters: Dauerhaftes Selbstlösen erzeugt Abhängigkeit statt Befähigung. Die Wirksamkeit zeigt sich erst daran, was bleibt, wenn er geht.
← Alle ThemenIm Quiz üben