Interviewfragen für Scrum Master, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Übe jede kurze Antwort laut und häng dann eine eigene Geschichte an: das Team, das Problem, was du getan hast und was danach passiert ist, auch das, was nicht funktioniert hat. Viele Interviews enthalten ein Rollenspiel oder eine kurze Moderation, etwa fünf Minuten einer Retrospektive mit den Interviewern; übe also das Tun, nicht nur das Erklären.

Was ein Scrum Master können muss

• Der Scrum Guide: die drei Verantwortlichkeiten, die fünf Events, die drei Artefakte und das Commitment hinter jedem, und die Werte von ScrumDen Scrum Guide so gut kennen, dass du den Grund hinter jedem Event erklären und anpassen kannst, ohne ihn zu verlieren..
• Fluss: die Praktiken von KanbanDie Arbeit sichtbar machen, die laufende Arbeit begrenzen und den Fluss steuern; oft neben Scrum oder statt Sprints. und die Kennzahlen des Flusses, und wann sie einem Team besser passen als Sprints.
• Moderation und Coaching: Events, die Menschen nützlich finden, Fragen, die ein Gespräch öffnenGute Fragen stellen, zuhören und Unangenehmes freundlich sagen; der größte Teil des Jobs ist Gespräch., und der Umgang mit Konflikten.
• Die Organisation rund um das Team: Stakeholder, Führungskräfte, Budgets und Skalierung über viele Teams.
• Werkzeuge: ein Board in JiraBoards, Workflows und einfache Berichte in Jira so einrichten, dass sie die Arbeit zeigen, ohne dass das Werkzeug das Team führt. oder Azure DevOps, Teamseiten in Confluence und ein Whiteboard wie Miro für Workshops aus der Ferne.

Der Scrum Guide und die Rolle

Was verlangt der Scrum Guide von 2020 von einem Scrum Master?

Worauf sie achten: dass du den aktuellen Guide kennst und die Rolle als verantwortlich für die Wirksamkeit siehst, nicht als Organisator von Meetings.

Kurze Antwort: „Der Scrum Guide von 2020 macht den Scrum Master für die Wirksamkeit des Scrum Teams verantwortlich. Der Scrum Master dient den Entwicklern, dem Product Owner und der Organisation: Er coacht Selbstmanagement, hilft dem Product Owner beim Produktziel und beim Backlog, beseitigt Hindernisse und hilft der Organisation, Scrum einzuführen. Der Guide nennt Scrum Master echte Führungskräfte, die dem Team und der Organisation dienen.“

Die ausführliche Antwort: Die Ausgabe von 2020 hat den alten Begriff Servant Leader durch diese Formulierung ersetzt, Rollen durch drei Verantwortlichkeiten ersetzt (Product Owner, Scrum Master, Entwickler) und das Produktziel als Commitment des Product Backlogs ergänzt. Im Alltag ist die Rolle meist unsichtbar, wenn sie funktioniert: Das Team plant, prüft und passt sich selbst an, und der Scrum Master wendet sich dem nächsten Hindernis zu, oft außerhalb des Teams.

Schwache Antwort: „Ich organisiere die Meetings und pflege das Board.“ Nachfrage: „Was bedeutet selbstmanagend?“ Das Team entscheidet, wer was wann und wie tut, im Rahmen des Sprintziels.

Geh die Scrum-Events durch. Welches würdest du ein Team nie auslassen lassen, und warum?

Worauf sie achten: dass du den Zweck jedes Events kennst, nicht nur seinen Namen.

Kurze Antwort: „Der Sprint umfasst die anderen vier. Das Sprint Planning legt das Sprintziel und den Plan fest; das Daily Scrum prüft den Fortschritt zum Ziel und passt den Plan an; das Sprint Review prüft das Inkrement mit den Stakeholdern und passt das Backlog an; die Retrospektive verbessert, wie das Team arbeitet. Die Retrospektive würde ich nie auslassen lassen, weil durch sie alles andere besser wird.“

Die ausführliche Antwort: Jedes Event ist eine Gelegenheit, zu prüfen und anzupassen, und jedes hat eine Timebox: bis zu acht Stunden Planning für einen Sprint von einem Monat, fünfzehn Minuten für das Daily Scrum, vier Stunden Review und drei Stunden Retrospektive, kürzer bei kürzeren Sprints. Ein Inkrement ist ein nutzbares Stück des Produkts, das die Definition of Done erfüllt. Teams, die das Review auslassen, verlieren Feedback; Teams, die die Retrospektive auslassen, wiederholen ihre Probleme.

Schwache Antwort: „Das Daily Standup ist am wichtigsten, damit der Manager den Stand kennt.“ Nachfrage: „Das Team sagt, die Events kosten zu viel Zeit.“ Schau, welche Events sich nutzlos anfühlen und warum, und stell ihren Zweck wieder her, bevor du sie kürzt.

Events, die funktionieren

Das Daily Scrum ist zum Statusbericht an den Manager geworden. Was tust du?

Worauf sie achten: Moderation und den Mut, eine Gewohnheit gemeinsam mit den Beteiligten zu ändern.

Kurze Antwort: „Ich erinnere alle daran, wofür das Daily Scrum da ist: Die Entwickler prüfen den Fortschritt zum Sprintziel und passen ihren Plan an. Mit dem Manager spreche ich zuerst, unter vier Augen, und biete ihm einen anderen Weg an, den Fortschritt zu sehen, etwa das Board oder das Review. Dann helfe ich dem Team, es entlang des Ziels und des Boards zu führen, nicht Person für Person.“

Die ausführliche Antwort: Ein Statusbericht bringt Menschen dazu, sich zu verteidigen, statt einander zu helfen. Wer das Board von rechts nach links durchgeht, von fast fertig bis nicht begonnen, hält den Blick auf dem Fertigstellen. Braucht der Manager weiter Informationen, finde heraus, welcher Entscheidung sie dienen, und liefere sie auf anderem Weg. Halte das Daily Scrum bei fünfzehn Minuten und verlege das Lösen von Problemen auf die Zeit danach.

Schwache Antwort: „Ich bitte den Manager, nicht mehr zu kommen.“ Nachfrage: „Der Manager weigert sich.“ Bitte ihn, zwei Wochen lang still zuzuschauen, und zeig, was das Team gewinnt.

Wie leitest du eine Retrospektive, die wirklich zu Veränderung führt?

Worauf sie achten: dass Retrospektiven in deinen Teams Verbesserungen bringen, keine Klagen.

Kurze Antwort: „Ich wechsle das Format, damit die Leute dabeibleiben, sorge dafür, dass sich jeder zu sprechen traut, schaue auf Fakten aus dem Sprint und ende mit ein oder zwei konkreten Maßnahmen mit einem Verantwortlichen. Die nächste Retrospektive beginnt damit, diese Maßnahmen zu prüfen. Wenige Maßnahmen, die erledigt werden, schlagen eine lange Liste.“

Die ausführliche Antwort: Eine nützliche Form ist: den Rahmen setzen, Daten sammeln, Ursachen finden, entscheiden, was zu tun ist, und abschließen. Bring Daten mit, wo du kannst, etwa Durchlaufzeiten oder wie oft Arbeit blockiert war. Achte darauf, wer nicht spricht, und gib diesen Menschen andere Wege, etwa erst zu schreiben. Setz die Verbesserung auf das Product Backlog oder das Sprint Backlog, damit sie erledigt wird, und feiere, wenn sie wirkt.

Schwache Antwort: „Wir nehmen jedes Mal dieselben drei Fragen.“ Nachfrage: „Das Team schweigt in Retrospektiven.“ Finde heraus, warum, oft im Gespräch unter vier Augen; es kann am Vertrauen liegen, an einer dominanten Stimme oder an Maßnahmen, die nie umgesetzt wurden.

Das Product Backlog und die Definition of Done

Das Product Backlog ist schon wieder nicht bereit für das Sprint Planning. Wie hilfst du dem Product Owner?

Worauf sie achten: dass du den Product Owner unterstützt, ohne ihm das Backlog abzunehmen.

Kurze Antwort: „Ich finde heraus, warum: keine Zeit, ein unklares Produktziel oder Stories, die zu groß zum Planen sind. Dann helfe ich bei der Ursache: ein regelmäßiges Refinement mit den Entwicklern, Techniken zum Schneiden von Stories und ein klares Produktziel, nach dem sich das Backlog ordnen lässt. Der Product Owner bleibt für die Reihenfolge verantwortlich.“

Die ausführliche Antwort: Refinement ist laufende Arbeit, oft etwa ein Zehntel der Zeit des Teams, damit der obere Teil des Product Backlogs klar und klein genug zum Planen ist. Ein Product Owner, der in Meetings untergeht, braucht vielleicht Hilfe vom Management; das ist die Arbeit des Scrum Masters mit der Organisation. Coache den Product Owner darin, Ergebnisse und Akzeptanzkriterien zu formulieren; schreib das Backlog nie für ihn.

Schwache Antwort: „Ich schreibe die Stories selbst, damit wir anfangen können.“ Nachfrage: „Der Product Owner ist selten erreichbar.“ Mach die Kosten für den Auftraggeber sichtbar und vereinbare eine Mindestpräsenz.

Was ist eine Definition of Done, und wem gehört sie?

Worauf sie achten: dass du die Definition of Done als Zusage zur Qualität siehst, nicht als Checkliste an der Wand.

Kurze Antwort: „Die Definition of Done ist die gemeinsame Beschreibung der Qualität, die ein Inkrement erfüllen muss: zum Beispiel getestet, geprüft, dokumentiert und integriert. Hat die Organisation einen Standard, folgt das Team mindestens diesem; sonst erstellt das Scrum Team eine eigene. Arbeit, die sie nicht erfüllt, wird im Review nicht gezeigt und geht zurück ins Backlog.“

Die ausführliche Antwort: Eine starke Definition of Done beseitigt versteckte Arbeit, etwa Tests oder Sicherheitsprüfungen, die auf später verschoben werden. Teams heben sie mit der Zeit an, zum Beispiel durch automatische Releases über CI/CDWissen, warum automatische Builds, Tests und Releases einem Team erlauben, in jedem Sprint ein nutzbares Inkrement zu liefern., damit jedes Inkrement zu den Nutzern gehen könnte. Arbeiten mehrere Teams an einem Produkt, teilen sie eine Definition of Done.

Schwache Antwort: „Fertig heißt, der Entwickler hat fertig programmiert.“ Nachfrage: „Das Testen rutscht immer in den nächsten Sprint.“ Hol das Testen in den Sprint und in die Definition of Done, und plane mit dem Team weniger Arbeit, bis es passt.

Velocity, Kanban und Fluss

Wofür ist Velocity da, und was geht schief, wenn Manager sie zwischen Teams vergleichen?

Worauf sie achten: dass du Kennzahlen nutzt, um dem Team zu helfen, und es vor Missbrauch schützt.

Kurze Antwort: „Velocity ist die Menge an Arbeit, meist in Story Points, die ein Team in einem Sprint fertigstellt. Sie hilft diesem Team, die nächsten Sprints zu planen. Zwischen Teams bedeutet sie nichts, weil jedes Team anders schätzt; wer sie vergleicht, bringt Teams dazu, ihre Schätzungen aufzublähen, und beendet ehrliches Planen.“

Die ausführliche Antwort: Velocity steht nicht im Scrum Guide; sie ist eine Gewohnheit, die viele Teams nutzen. Will das Management Fortschritt sehen, biete stattdessen Ergebnisse an: erreichte Sprintziele, gelieferter Wert, die Zeit bis zu den Nutzern. Lies die DatenFlussdaten wie Durchlaufzeit und laufende Arbeit lesen, um ein nützliches Gespräch anzustoßen, nicht um Menschen zu bewerten. als Quelle für Fragen an das Team, nie für Ranglisten von Menschen.

Schwache Antwort: „Höhere Velocity heißt besseres Team.“ Nachfrage: „Die Velocity hat sich halbiert.“ Frag das Team: Krankheit, schwierigere Arbeit, mehr Support oder Schätzungen, die endlich ehrlich geworden sind.

Wann würdest du Kanban statt Sprints nutzen, und welche Kennzahlen des Flusses beobachtest du?

Worauf sie achten: dass du Kanban als eigene Arbeitsweise kennst, nicht als Scrum ohne Sprints.

Kurze Antwort: „Kanban passt zu Arbeit, die unvorhersehbar kommt, etwa Support oder Betrieb. Ich beobachte die laufende Arbeit, also wie viele Einträge begonnen und nicht fertig sind; die Durchlaufzeit, also wie lange ein Eintrag vom Start bis fertig braucht; den Durchsatz, also wie viele Einträge pro Woche fertig werden; und das Alter offener Einträge. Erst das Begrenzen der laufenden Arbeit verbessert den Fluss.“

Die ausführliche Antwort: Viele Scrum-Teams nutzen Praktiken von Kanban in ihren Sprints, und Scrum.org veröffentlicht genau dafür einen eigenen Guide. Little's Law verbindet die Kennzahlen: mehr laufende Arbeit heißt längere Durchlaufzeiten. Ein kumulatives Flussdiagramm zeigt, wo Arbeit wartet. Fang damit an, die Arbeit auf dem Board sichtbar zu machen, vereinbare Limits pro Spalte und sprich täglich mit dem Team über die ältesten Einträge.

Schwache Antwort: „Kanban ist für Teams, die nicht planen können.“ Nachfrage: „Das Team ignoriert die Limits.“ Frag, was passiert, wenn ein Limit erreicht ist; es ist ein Signal, beim Fertigstellen zu helfen, nicht mehr anzufangen.

Hindernisse, Konflikte und Stakeholder

Wie gehst du mit einem Hindernis um, das das Team nicht selbst beseitigen kann?

Worauf sie achten: dass du an der Organisation arbeitest, nicht nur im Team.

Kurze Antwort: „Ich mache es sichtbar, mit seinen Kosten: wie lange Arbeit wartet, wie oft. Dann gehe ich zu der Person, die es ändern kann, mit einem Vorschlag, nicht nur mit einer Beschwerde. Ich verfolge es bis zum Ende und sage dem Team, wo es steht. Bei Hindernissen, die das Team selbst lösen kann, coache ich es, statt sie ihm abzunehmen.“

Die ausführliche Antwort: Typische Hindernisse außerhalb des Teams sind langsame Freigaben, geteilte Umgebungen, fehlende Zugänge und Abhängigkeiten von anderen Teams. Führe eine sichtbare Liste der Hindernisse, gruppiere sie nach Ursache und bring Muster zum Management. Manche dauern Monate; Führen ohne WeisungsbefugnisFühren ohne Weisungsbefugnis: coachen, moderieren und das System rund um das Team verändern. heißt, Verbündete zu gewinnen und Ergebnisse in kleinen Schritten zu zeigen.

Schwache Antwort: „Ich eskaliere alles an den Manager.“ Nachfrage: „Das Hindernis ist der Manager.“ Sprich zuerst mit ihm, unter vier Augen, mit Fakten und einem Angebot zu helfen.

Zwei Entwickler streiten in jedem Refinement offen. Wie gehst du mit dem Konflikt um?

Worauf sie achten: dass du Menschen durch einen Konflikt helfen kannst, ohne Partei zu ergreifen.

Kurze Antwort: „Ich spreche zuerst mit jedem allein, um zu verstehen, was dahintersteckt. Dann helfe ich dem Team, Arbeitsvereinbarungen zu treffen, wie es entscheidet, und im Refinement moderiere ich den Streit über die Fakten: Optionen, Kriterien, ein kleines Experiment. Manche Konflikte sind gesund; persönliche Angriffe nicht.“

Die ausführliche Antwort: Konflikte haben oft eine Ursache im System: unklare Zuständigkeit, Druck oder unterschiedliche Vorstellungen von Qualität. Benenne, was du siehst, ohne Schuld zuzuweisen, und gib den ruhigeren Teammitgliedern eine Stimme, damit nicht zwei für alle entscheiden. Wird es persönlich und ändert sich nichts, hol die disziplinarische Führungskraft dazu, denn Leistung und Verhalten sind ihre Aufgabe.

Schwache Antwort: „Ich lasse den Erfahreneren entscheiden.“ Nachfrage: „Einer von beiden droht zu kündigen.“ Hör zu, nimm es ernst und bezieh die Führungskraft ein.

Ein Stakeholder geht am Product Owner vorbei und bittet die Entwickler direkt um Arbeit. Was tust du?

Worauf sie achten: dass du den Fokus und die Verantwortung des Product Owners schützt, mit Takt.

Kurze Antwort: „Ich danke den Entwicklern, dass sie es ansprechen, und rede mit dem Stakeholder: Sein Bedarf ist echt, und der Weg dorthin führt über den Product Owner und das Product Backlog. Ich lade ihn zum Sprint Review ein, wo er den Fortschritt sieht und das Backlog beeinflussen kann.“

Die ausführliche Antwort: Anfragen an der Seite vorbei heißen oft, dass der Stakeholder dem Prozess noch nicht vertraut. Mach das Backlog und das Review für ihn nützlich und hilf dem Product Owner, die Reihenfolge zu erklären. Die Arbeit mit StakeholdernDem Product Owner bei der Arbeit mit Stakeholdern helfen: Reviews, zu denen sie kommen, und Wünsche, die über das Backlog laufen. ist vor allem Aufgabe des Product Owners; der Scrum Master coacht sie und schützt den Sprint.

Schwache Antwort: „Ich sage dem Stakeholder, er soll gehen.“ Nachfrage: „Es ist der CEO.“ Dasselbe Prinzip, nur schneller: Hol sofort den Product Owner dazu und entscheide gemeinsam mit ihm, ob sich das Sprintziel ändern muss.

Wie schätzt dein Team, und was sagst du, wenn das Management einen festen Termin will?

Worauf sie achten: ehrliche Prognosen statt Versprechen.

Kurze Antwort: „Die Entwickler schätzen, mit Story Points, T-Shirt-Größen oder durch Zählen der Einträge. Für einen Termin helfe ich dem Product Owner, aus echten Daten eine Prognose zu machen, als Spanne mit einer Wahrscheinlichkeit, und sie in jedem Sprint zu aktualisieren. Steht der Termin fest, halten wir ihn und reden über den Umfang.“

Die ausführliche Antwort: Prognosen aus dem Durchsatz, etwa wie viele Einträge das Team pro Sprint fertigstellt, sind oft so gut wie detaillierte Schätzungen und viel günstiger. Zeig, was bis zum Termin wahrscheinlich ist und was nicht, und lass den Product Owner das Backlog so ordnen, dass die wertvollste Arbeit zuerst kommt. Ein Termin, der ohne das Team versprochen wurde, ist ein Wunsch.

Schwache Antwort: „Wir zählen die Story Points zusammen und versprechen den Termin.“ Nachfrage: „Die Prognose zeigt, dass der Termin verfehlt wird.“ Sag es früh, mit Optionen: weniger Umfang, ein späterer Termin oder ein Hindernis, das beseitigt wird.

Skalierung, Remote-Teams und Lieferung

Wie arbeiten mehrere Teams an einem Produkt, und was weißt du über SAFe?

Worauf sie achten: dass du die üblichen Wege der Skalierung kennst und sie ohne Dogma beurteilst.

Kurze Antwort: „Mehrere Teams an einem Produkt teilen ein Product Backlog, ein Produktziel und eine Definition of Done, und sie integrieren ihre Arbeit oft. SAFe, das Scaled Agile Framework, fasst Teams in einem Agile Release Train zusammen, der im PI Planning gemeinsam plant, einer großen Planung im selben Raum zu Beginn jedes Program Increments von etwa acht bis zwölf Wochen. LeSS und Nexus sind leichtere Wege zu skalieren.“

Die ausführliche Antwort: In SAFe übernimmt der Release Train Engineer den Teil des Scrum Masters für den ganzen Train. Das Framework passt zu großen Organisationen, in denen viele Teams gemeinsam planen müssen; Kritiker finden es schwerfällig. Egal welches Framework: Die schwierigen Teile sind dieselben, nämlich Abhängigkeiten zwischen Teams, eine gemeinsame Integration und eine Gruppe von Product Ownern, die sich auf eine Reihenfolge einigt.

Schwache Antwort: „Skalieren heißt mehr Meetings.“ Nachfrage: „Zwei Teams blockieren sich ständig gegenseitig.“ Mach die Abhängigkeit sichtbar, plane sie mit beiden Teams gemeinsam und frag, ob die Teams richtig entlang des Produkts geschnitten sind.

Wie führst du Scrum mit einem Remote-Team, das über Zeitzonen verteilt ist?

Worauf sie achten: dass du Events, Vertrauen und Fokus ohne gemeinsamen Raum lebendig halten kannst.

Kurze Antwort: „Ich vereinbare Kernzeiten, die sich für die Events überschneiden, behalte Kameras und kurze Timeboxen bei und verlege viel vom Gespräch ins Schriftliche. Workshops aus der Ferne laufen auf einem Whiteboard wie Miro, und das Board in Jira oder Azure DevOps ist die gemeinsame Wahrheit. Ich führe öfter Einzelgespräche, weil Probleme länger verborgen bleiben.“

Die ausführliche Antwort: Wechsle die Termine, damit nicht immer dieselben Leute nachts dabei sind. Halte Entscheidungen auf Teamseiten in Confluence fest. Hol das Team, wenn möglich, ein paar Mal im Jahr persönlich zusammen, für ein Planning oder eine Retrospektive, denn Vertrauen, das von Angesicht zu Angesicht entsteht, hält.

Schwache Antwort: „Remote funktioniert genauso wie vor Ort.“ Nachfrage: „Die Hälfte des Teams spricht in Remote-Events nie.“ Lass zuerst schreiben, arbeite in kleineren Gruppen und lade direkt ein.

Das Team schließt seine Stories ab, aber monatelang erreicht nichts die Nutzer. Was tust du?

Worauf sie achten: dass es dir um gelieferten Wert geht, nicht um geschlossene Stories.

Kurze Antwort: „Ich zeichne den Weg von fertig bis zum Nutzer auf und finde, wo Arbeit wartet: manuelle Tests, Freigaben für Releases, ein getrenntes Betriebsteam. Dann arbeite ich mit dem Team und der Organisation an der größten Wartezeit, oft automatische Tests und Releases über CI/CD, und an einer Definition of Done, die beim Nutzer endet.“

Die ausführliche Antwort: Ein Sprint Review ohne etwas Nutzbares ist eine Demo, kein Review. Miss die Zeit von der Idee bis zum Nutzer und mach sie sichtbar. Manche Wartezeiten sind Regeln, etwa Freigaben von Änderungen in regulierten Firmen; das Ziel ist, sie schneller zu erfüllen, nicht sie zu umgehen.

Schwache Antwort: „Releases sind nicht Sache des Scrum Masters.“ Nachfrage: „Der Betrieb liefert einmal im Quartal aus.“ Lade die Kollegen aus dem Betrieb zu einem Review ein und starte gemeinsam mit ihnen ein kleines automatisches Release.

Senior Scrum Master, Agile Coach und Head of Agile Transformation

Diese Fragen kommen bei Rollen als Senior Scrum Master, Agile Coach, Enterprise Agile Coach und Head of Agile Transformation, wo die Arbeit von einem Team zu vielen Teams und ihren Führungskräften wandert.

Wie würdest du als Agile Coach einer ganzen Abteilung helfen, agile Arbeitsweisen einzuführen?

Worauf sie achten: dass du eine Organisation mit ihren Führungskräften veränderst, nicht durch das Ausrollen eines Frameworks.

Kurze Antwort: „Ich fange mit dem Warum an: was die Abteilung verbessern will, etwa die Zeit bis zum Markt oder die Qualität, und woran wir es erkennen. Dann fange ich klein an, mit Teams und Führungskräften, die wollen, zeige Ergebnisse und verbreite, was funktioniert. Auch die Führungskräfte ändern sich: wie sie Ziele setzen, Arbeit finanzieren und Erfolg messen.“

Die ausführliche Antwort: Eine Transformation dreht sich vor allem um Strukturen und Gewohnheiten außerhalb der Teams: Budgets fest pro Projekt, Freigaben, Karrierewege, wie Führungskräfte ihre Zeit verbringen. Ein Enterprise Agile Coach arbeitet daran mit der Führungsebene und entwickelt Coaches und Scrum Master, die die Veränderung tragen. Miss Ergebnisse, nicht die Zahl der Teams, die „Scrum machen“.

Schwache Antwort: „Ich würde alle in Scrum schulen und es in drei Monaten ausrollen.“ Nachfrage: „Die Führungsebene sagt Ja, ändert aber nichts.“ Mach die Kosten sichtbar, fang mit einer Führungskraft an, die es will, und zeig den anderen das Ergebnis.

Dein Lebenslauf für diese Fragen

Ein Interviewer greift jede Zeile deines Lebenslaufs auf und fragt, wie das Team vorher und nachher aussah. Schreib Zeilen, die das beantworten, jede unter dem Job, in dem es passiert ist:

Wenn du deinen Lebenslauf an einem echten Job als Scrum Master bewertest, siehst du, welche Veränderungen im Team der Anzeige wichtig sind und welche dein Lebenslauf noch nicht belegt.