Scrum Master Vorstellungsgespräch: Fragen & Antworten (mit Musterantworten)

Musterantwort

Ich verstehe mich als dienende Führungskraft, die dem Team hilft, eigenständig und effektiv zu arbeiten, statt Aufgaben zu verteilen. Ich sorge dafür, dass Scrum verstanden und gelebt wird, beseitige Hindernisse und schütze das Team vor Störungen von außen. Gleichzeitig coache ich Product Owner und Organisation zu agilem Denken. Mein Erfolg misst sich daran, ob das Team mit der Zeit selbstorganisierter und der Wertfluss spürbar besser wird.

Musterantwort

Ich mache das Hindernis zunächst transparent, etwa über das Impediment Board, und kläre die genaue Auswirkung auf das Sprint-Ziel. Wenn es außerhalb meines Einflussbereichs liegt, eskaliere ich gezielt an die richtige Stelle im Management und bleibe dranbleibend an der Lösung. Parallel suche ich mit dem Team nach Workarounds, damit der Fortschritt nicht völlig stockt. So hatte ich einmal eine standortübergreifende Lizenzblockade durch beharrliche Eskalation in einer Woche gelöst.

Musterantwort

Ich nehme das Feedback ernst und untersuche, ob Retros bisher ohne sichtbare Konsequenzen blieben, was Frust erzeugt. Ich variiere die Formate, um sie lebendiger zu machen, und stelle sicher, dass aus jeder Retro maximal ein bis zwei konkrete, nachverfolgte Maßnahmen entstehen. Wenn das Team sieht, dass sich tatsächlich etwas verbessert, kehrt das Engagement zurück. Bei einem Team stieg so die Beteiligung deutlich, nachdem die ersten umgesetzten Maßnahmen Wirkung zeigten.

Musterantwort

Ich suche zuerst das Gespräch, um die Ursache zu verstehen, oft steckt geschäftlicher Druck oder unklare Roadmap dahinter. Ich erkläre, wie häufige Sprint-Eingriffe Fokus und Vorhersehbarkeit zerstören, und biete als Lösung kürzere Sprints oder einen klaren Prozess für echte Notfälle an. Dabei schütze ich das laufende Sprint-Ziel, ohne den PO zu blockieren. So fand ich mit einem PO eine Regel, dass nur kritische Vorfälle den Sprint unterbrechen dürfen.

Musterantwort

Mich reizt, dass Sie mehrere Teams skalieren und damit spannende Herausforderungen rund um teamübergreifende Abstimmung mitbringen. Ihre Ausschreibung erwähnt, dass agile Reife noch im Aufbau ist, und genau dort sehe ich meine Stärke im Coaching von Teams und Organisation. Ich möchte zu einer Kultur beitragen, in der Teams Verantwortung übernehmen und Wert kontinuierlich liefern. Außerdem passt Ihr Produktfokus gut zu meiner bisherigen Erfahrung.

Scrum kennt den Sprint als Container sowie Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective. Das Planning legt das Sprint-Ziel fest, das Daily synchronisiert den Fortschritt, das Review inspiziert das Inkrement mit Stakeholdern und die Retrospektive verbessert die Arbeitsweise. Jedes Event schafft eine formale Gelegenheit zu Inspektion und Anpassung.

Ein Projektleiter steuert klassisch Umfang, Zeit und Budget und trifft oft direktive Entscheidungen. Der Scrum Master ist eine dienende Führungskraft ohne Weisungsbefugnis, die Prozess und Team befähigt und Hindernisse beseitigt. Die Verantwortung für das Was liegt beim Product Owner, das Wie beim Entwicklungsteam.

Velocity ist eine empirische Kennzahl, wie viele Story Points ein Team in vergangenen Sprints durchschnittlich abgeschlossen hat, und dient der Prognose. In modernem Scrum spricht man statt Commitment von einer Forecast, also einer Vorhersage des Teams, da ein starres Commitment Druck erzeugt. Velocity sollte intern zur Planung dienen und nicht als Leistungsbewertung missbraucht werden.

Die Definition of Done ist ein gemeinsames, verbindliches Verständnis, wann ein Inkrement wirklich fertig und auslieferbar ist, etwa getestet und dokumentiert. Die Definition of Ready beschreibt, wann ein Backlog Item klar genug ist, um in einen Sprint aufgenommen zu werden. Beide schaffen Klarheit und vermeiden halbfertige oder unklare Arbeit.

Frameworks wie SAFe, LeSS oder Nexus koordinieren mehrere Teams an einem gemeinsamen Produkt. Sie führen zusätzliche Abstimmungsmechanismen ein, etwa gemeinsames Backlog-Refinement, ein integriertes Inkrement und teamübergreifende Synchronisationsmeetings. Ziel ist, Abhängigkeiten sichtbar zu machen und einen gemeinsamen Wertfluss zu sichern.

Ich übernahm ein Team mit verfehlten Zielen und stillen Konflikten in den Dailies (Situation). Meine Aufgabe war, Zusammenarbeit und Lieferfähigkeit zu verbessern (Task). Ich habe in Einzelgesprächen Vertrauen aufgebaut, die Retros auf konkrete Maßnahmen fokussiert und unklare Anforderungen über besseres Refinement adressiert (Action). Über mehrere Sprints stabilisierte sich die Velocity und das Team begann, Probleme offen anzusprechen (Result).

Ein erfahrener Entwickler hielt die Dailies für Zeitverschwendung (Situation). Ich sollte den Wert vermitteln, ohne ihn zu bevormunden (Task). Ich habe das Daily auf Hindernisse und Synchronisation statt Statusbericht ausgerichtet und ihn gebeten, es zwei Wochen ergebnisoffen zu testen (Action). Danach nutzte er das Daily aktiv, um Blocker früh anzusprechen, und sein Widerstand verschwand (Result).

Mitten im Sprint fiel ein zentrales Teammitglied krankheitsbedingt aus (Situation). Ich sollte helfen, das Sprint-Ziel realistisch zu retten (Task). Ich habe mit dem Team den Umfang neu bewertet, Wissen über Pair Programming verteilt und mit dem PO eine reduzierte, aber wertvolle Lieferung abgestimmt (Action). Das Team lieferte das Kernziel termingerecht, und der Wissensaustausch reduzierte künftige Single Points of Failure (Result).

Das Management forderte feste Liefertermine für ein noch unklares Feature (Situation). Ich sollte realistische Erwartungen schaffen, ohne das Vertrauen zu beschädigen (Task). Ich habe mit empirischen Daten zur Velocity und einem Forecast-Bereich statt eines Fixtermins argumentiert und Risiken transparent gemacht (Action). Das Management akzeptierte den Korridor, und das Team arbeitete ohne unrealistischen Druck (Result).