Wie man als SCRUM Master (PSM I) zertifiziert wird?

Ein praxistauglicher Lern- und Denkleitfaden für Menschen, die Scrum wirklich verstehen (und die Prüfung souverän bestehen) wollen

Kurzfassung für Eilige: Lies den Scrum Guide mehrere Male wirklich aktiv, trainiere mit dem Scrum Open und verwandten Assessments, lerne die Warum-Ebene hinter Regeln und Begriffen, übe das Erkennen typischer Fallen – und nutze in der Prüfung die Zeit mit System. Der Rest dieses Textes macht daraus einen vollständigen, gut verdaulichen Lernpfad mit vielen Denkanstößen, Mini-Drills und Praxisbezügen.

Warum dieser Text anders aufgebaut ist

Statt einer klassischen „Roadmap“ oder reinen Tipp-Liste bekommst du hier einen Werkzeugkasten in Form von Bausteinen, die du modular einsetzen kannst:

1. Mindset & Grundlagen – Worum es bei Scrum wirklich geht (und worum nicht).
2. Begriffe, die oft verwechselt werden – und wie du sie sauber auseinanderhältst.
3. Die „Warum“-Ebene – typische Prüfungsfallen aufdecken, indem du Gründe verstehst.
4. Mini-Drills – kurze Denkaufgaben mit knappen Lösungen.
5. Examenstaktik – Zeitmanagement, Suchstrategie, Stresskontrolle.
6. Artefakte & Commitments – wie du die 2020er-Logik der Commitments sicher beherrschst.
7. Accountabilities – wofür Scrum Master, Product Owner und Developers wirklich verantwortlich sind.
8. Ereignisse – Timeboxen, Ziele, Einladungen, Antipatterns.
9. Skalierung / Nexus-Hinweise – nur so viel, wie für PSM I hilft.
10. Realität vs. Prüfung – was „in echt“ oft passiert und warum die Prüfung trotzdem recht hat.
11. Lernplan für 25–30 Netto-Stunden – als Orientierung, nicht als starre Agenda.
12. Glossar light – die heiklen Begriffe auf einer Seite.

Du kannst die Abschnitte in beliebiger Reihenfolge lesen. Jeder Baustein steht für sich, zusammen bilden sie eine robuste Vorbereitung.

1) Mindset & Grundlagen – Empirie vor Theater

Empirie ist der Kern: Transparenz → Inspektion → Adaption. Ohne echte Transparenz ist alles andere Schein. Die fünf Scrum-Werte halten das Team zusammen: Commitment, Focus, Openness, Respect, Courage.
Die Prüfung testet, ob du dieses Gerüst anwendest – nicht, ob du Folien auswendig kannst.

Typische Denkfehler, die Punkte kosten:

• Scrum als Prozessvorschrift verstehen („am Dienstag muss Feature-X fertig sein“). Richtig: Scrum ist ein Rahmen, kein Kochrezept.
• Scrum Master als Chef – falsch. Er/Sie ist Leader who serves, fokussiert auf das Ermöglichen von Wirksamkeit.
• Daily als Status an den Scrum Master – falsch. Daily = Event für die Developers, zur Plan-Adaption für das Sprint Goal.
• Retro als Kummerkasten – falsch. Retro = datengestützte Inspektion von Menschen, Prozessen, Tools → konkrete Verbesserungs-Items im nächsten Sprint.

Merksatz: Wenn du zwischen „Kontrolle von Menschen“ und „Kontrolle von Arbeit mittels Transparenz“ wählen musst – Scrum wählt immer Letzteres.

2) Begriffe, die oft verwechselt werden (und wie du sie trennscharf machst)

Rolle vs. Accountability
Der Scrum Guide 2020 benutzt Accountabilities (Verantwortlichkeiten) – keine „Rollen“. Das ist mehr als Wortkosmetik: Es signalisiert, dass Wer weniger wichtig ist als Wofür.

Definition of Done vs. Acceptance Criteria

• DoD: Teamweite (Produkt-/Organisation-weite) Qualitätslatte pro Increment.
• Acceptance Criteria: Spezifische Bedingungen für ein PB-Item.
  Die Prüfung liebt diese Unterscheidung.

Product Goal vs. Sprint Goal

• Product Goal: mittelfristige Ausrichtung des Produkts.
• Sprint Goal: ein Fokus fürs Jetzt, Leuchtturm des Sprints.
  Frag dich bei jeder Aufgabe: Hilft das dem Sprint Goal? – wenn nein, raus damit.

Product Backlog vs. Sprint Backlog

• Product Backlog: geordnete Liste aller wünschenswerten Produktänderungen.
• Sprint Backlog: Forecast der Developers + Plan für das Erreichen des Sprint Goal.
  Nicht der Scrum Master, nicht der Product Owner „bestellt“ Tasks. Developers planen.

3) Die „Warum“-Ebene – warum 15 Minuten, warum kein CEO in der Retro?

• Daily = 15 Minuten: Timebox zwingt zur Fokussierung auf Adaption der Arbeit fürs Sprint Goal statt Status-Geschichten. Längere Dailies → oft Status/Reporting → verschwendete Zeit.
• CEO in der Retro: Machtgefälle killt Openness & Courage. Wenn Führung teilnehmen will, dann als eingeladener Lernender und ggf. außerhalb der Retro.
• Mikromanagement im Sprint: Widerspricht Selbstmanagement der Developers. Orientierung via Sprint Goal, nicht via Task-Zerfleddern und tägliche Umpriorisierung.

Prüfungs-Hinweis: Wo immer Selbstmanagement vs. Mikromanagement gegeneinander stehen – die Guidelogik bevorzugt Selbstmanagement plus klares Ziel.

4) Mini-Drills (mit kurzen Lösungen)

Drill 1: Wer ist für die Wirksamkeit des Scrum Teams verantwortlich?
Lösung: Scrum Master – accountable für die Wirksamkeit; er/sie ermöglicht Scrum.

Drill 2: Darf der Product Owner dem Team Aufgaben zuweisen?
Lösung: Nein. PO ordnet das Product Backlog; Developers planen wie sie das Sprint Goal erreichen.

Drill 3: Woran misst man Fortschritt in Scrum?
Lösung: Am Increment und am Fortschritt Richtung Product Goal/Sprint Goal – nicht an Story Points an sich.

Drill 4: Wer ändert die Definition of Done?
Lösung: Das Scrum Team (oft mit organisationalen Standards harmonisiert). Nicht der PO allein, nicht der SM allein.

Drill 5: Muss jedes Sprint-Backlog vollständige Tasks enthalten, bevor der Sprint startet?
Lösung: Nein. Genug, um zu starten. Der Plan emergiert.

5) Examenstaktik – wie du 60 Minuten souverän managst

• Technik: Die PSM-I-Prüfung ist online, unproctored. Du kannst den Scrum Guide offen haben – die Zeit ist knapp, also gezielt suchen (Strg/Cmd+F).
• Pacing: 80 Fragen / 60 Minuten → Ø 45 Sek pro Frage. Erster Durchlauf: instinktive Antworten setzen, Uneindeutiges mit „Flag“ markieren. Zweiter Durchlauf: nur noch markierte Fragen.
• Stolperworte: always, never, must, only – oft falsch (außer bei Definitionen). „Best“/„primary“ → prüft Fokus (z. B. Daily = Plan-Adaption).
• Guide-Suche: Suche nach Commitments („Product Goal“, „Sprint Goal“, „Definition of Done“), nach den Ereignissen, nach „Accountabilities“.
• Ausrichtung: In Zweifelsfällen gewinnt, was die Empirie stützt: Transparenz schaffen → inspizieren → anpassen.

6) Artefakte & Commitments (2020er-Logik sicher beherrschen)

Artefakt → Commitment → Zweck

• Product Backlog → Product Goal → Ausrichtung & Fokus fürs Produkt.
• Sprint Backlog → Sprint Goal → Fokus für den Sprint; gemeinsam getragener Nordstern.
• Increment → Definition of Done → Transparente Qualität; „fertig“ ist nicht verhandelbar.

Prüfungsfalle: Wenn ein Increment die DoD nicht erfüllt, ist es kein „Done“-Increment und darf nicht released werden (kann trotzdem nützlich sein, um Lernen zu erzeugen – aber es zählt nicht als „Done“).

7) Accountabilities präzise

• Scrum Master: accountable für Wirksamkeit; coacht Team & Organisation im Verständnis von Scrum; entfernt Impediments (indem er/sie das System verbessert, nicht indem er/sie Tasks übernimmt).
• Product Owner: accountable für Wertmaximierung des Produkts; ordnet das Product Backlog; kommuniziert Product Goal; entscheidet, wann Released wird.
• Developers: accountable für Plan & Qualität; schaffen Einblicke (Transparenz), passen den Plan täglich an, halten die DoD ein.

Grenzfälle: Ein PO „ordnet“ nicht Sprint-Tasks. Ein SM „besitzt“ nicht die Meetings, sondern stellt sicher, dass sie stattfinden, verstehen und wertstiftend sind.

8) Ereignisse – Timebox, Ziel, typische Antipatterns

Sprint

• Container für alle Events; max 1 Monat. Keine Änderungen, die das Sprint Goal gefährden.
• Abbruch nur durch PO – selten, wenn Sprint Goal obsolet.

Sprint Planning

• Beantwortet 3 Fragen: Warum (Sprint Goal), Was (aus PB), Wie (Plan).
• Achtung: Plan ist der Developers-Plan.
• Richtwerte: für 1-Monats-Sprint bis zu 8 h, kürzer bei kürzerem Sprint.

Daily Scrum

• 15 Minuten, gleiche Zeit, gleicher Ort wenn möglich.
• Output: angepasster Plan für die nächsten 24 h. Kein Status an Manager.

Sprint Review

• Stakeholder-Dialog am produktiven Increment. Kein Abhaken-Ritual. Inspektion von Product Goal, Markt, Risiken → Adaptation des Product Backlog.

Sprint Retrospective

• Systematisch: Menschen, Prozesse, Tools. Mindestens eine konkrete Verbesserung ins nächste Sprint Backlog.

Antipatterns auf einen Blick

• Dailies als Reporting
• Planning ohne Sprint Goal
• Review als Folien-Show statt Produkt
• Retro ohne beschlossene Experimente
• PO „ordnet“ Tasks im Sprint

9) Nexus / Skalierung – genau so viel, wie PSM I braucht

PSM I erwartet kein Nexus-Detailwissen, aber typische Fragen prüfen die Scrum-Logik bei mehreren Teams:

• Ein Product → ein Product Backlog → ein Product Goal.
• Jedes Team hat eigenes Sprint Goal, doch Abstimmung ist nötig (z. B. über integrative Events/Absprachen).
• Definition of Done sollte konsistent sein, damit Increments zusammen integrierbar sind.

10) Realität vs. Prüfung – wie du „echte Welt“ korrekt in die Antworten übersetzt

In vielen Firmen: Meetings länger, Manager in Dailies, mehr Reports, wechselnde Ziele. In der Prüfung gilt die Essenz des Guides:

• Selbstmanagement > Mikromanagement
• Ziel-Fokus > Feature-Abarbeitung
• Transparenz > politische Schönfärberei
• Lernen > Schuldzuweisung

Wenn eine Antwort „so läuft’s bei uns“ vs. „so will’s der Guide“ bietet, gewinnt die Guide-Logik.

11) Lernplan (25–30 Netto-Stunden, flexibel einsetzbar)

Kein starres Programm, sondern Anhalt, wie du Tiefgang und Tempo balancierst.

Block A – Fundament (6–8 h)

• Scrum Guide (englisch) 3× aktiv lesen (Markierungen, Randnotizen).
• Nach jedem Lesen eigene Fragen formulieren („Warum …?“) und im Guide beantworten.

Block B – Prüfungslogik (4–6 h)

• Scrum Open wiederholt, bis du mehrfach 100 % erreichst.
• Zusätzlich: Product Owner Open und Nexus Open (zur Begriffsschärfung).
• Nach jedem Fehler: Stelle dir Warum-Frage und Belegstelle im Guide suchen.

Block C – Deep Dives (6–8 h)

• Commitments & Artefakte, DoD vs. Akzeptanzkriterien, Sprint Goal vs. Product Goal.
• Accountabilities: Wer ist wofür accountable?
• Ereignisse: Ziel, Output, Antipatterns.
• Mini-Drills erstellen (eigene Fragen!) + kurze Lösungen.

Block D – Examensimulation (3–4 h)

• Eine volle Simulation (Zeitdruck).
• Nacharbeit nur auf markierte Unsicherheiten, keine Breitschusspflege.

Block E – Feinschliff (4–5 h)

• Begriffe, die du verwechselst, auf 1 Seite klären (Glossar light).
• „Warum“-Liste 10× – deine häufigsten Irrtümer und ihre Korrektur.
• Schlaf. Ja, wirklich.

12) Häufige Fallen mit „Guide-konformen“ Korrekturen

• „Scrum Master moderiert jedes Event“ → Er/Sie sorgt für Verstehen und Wirksamkeit, muss nicht moderieren.
• „PO nimmt Stories in den Sprint“ → Developers treffen den Forecast; PO liefert Ziel & Ordnung.
• „Daily beantwortet 3 Fragen“ → Das war früher eine Option; heute zählt Plan-Adaption.
• „Review = Abnahme“ → Nein. Inspektion des Increments und des Produkts im Marktkontext.
• „DoD ist gleich Akzeptanzkriterien“ → siehe oben: global vs. Item-spezifisch.

13) Prüfungsnahe Übungsfragen (Kurzform)

1. Wer ist für den Wert des Produkts verantwortlich?
   Antwort: Product Owner.
2. Was ist das primäre Ziel des Daily?
   Antwort: Adaption des Plans für die nächsten 24 h, um das Sprint Goal bestmöglich zu erreichen.
3. Wer kann den Sprint abbrechen?
   Antwort: Product Owner.
4. Was passiert, wenn das Increment die DoD nicht erfüllt?
   Antwort: Es ist nicht Done, kann nicht als Done präsentiert/released werden.
5. Wie viele Product Backlogs darf es für ein Produkt geben?
   Antwort: Genau eines.

14) Such-Strategie im Scrum Guide (wenn du nachschlagen willst)

• „Commitment“ → springt zu Product Goal / Sprint Goal / DoD.
• „Daily“ / „15 minutes“ → Timebox & Zweck.
• „Accountabilities“ → Abgrenzungen der drei Verantwortlichkeiten.
• „Increment“ / „Done“ → Qualität & Release-Fähigkeit.
• „Sprint Goal“ → Fokus, Handlungsspielraum im Sprint.

Zeitdisziplin: Wenn du nach 20–25 Sek noch keine sichere Stelle hast – entscheide nach Guide-Logik und markiere die Frage.

15) Wenn du Praxisluft schnuppern willst (und warum das hilft)

Die Prüfung prüft Verständnis, echte Wirksamkeit entsteht erst im Team. Jede Praxisgelegenheit (Schulung, Shadowing, Communities, internes Projekt) hilft, die „Warum“-Ebene zu fühlen:

• Konflikte um Scope vs. Sprint Goal
• Stakeholder-Druck vs. Empirie
• Definition of Done als Qualitätsvertrag, nicht als Wunschliste

Nebeneffekt: Mit Praxis erkennst du Prüfungsfallen schneller, weil du die Konsequenzen im Kopf spürst.

16) Kurz-Glossar der heiklen Begriffe

• Accountability: Verantwortlichkeit (nicht „Rolle“).
• Self-managing: Team organisiert wie es Arbeit erledigt, nicht was es als Ziel verfolgt (das kommt über Sprint Goal/Product Goal).
• Forecast: Selbst gewählter Plan der Developers, kein Versprechen an Management.
• DoD: verbindliche Qualitätsgrenze für jedes Increment.
• Product Goal: langfristiger Fokus; ein Ziel pro Product Backlog.
• Sprint Goal: eins pro Sprint; Leitstern für Entscheidungen.
• Increment: potenziell releasefähige Erweiterung des Produkts.

17) „Reality Checks“ – Mini-Dialoge, die dir in der Prüfung helfen

Manager: „Ich will jeden Tag den Status im Daily hören.“
Scrum Master: „Gern Transparenz – aber das Daily gehört den Developers, um ihren Plan anzupassen. Lass uns ein separates Info-Format schaffen, das nicht stört.“

CEO: „Ich komme in die Retro, damit es schneller geht.“
Scrum Master: „Wir freuen uns über Unterstützung. Die Retro braucht psychologische Sicherheit. Lass uns Ergebnisse der Retro teilen und gezielt mit dir Hindernisse adressieren.“

Product Owner: „Ich teile Tasks zu, dann geht es schneller.“
Developers: „Unser Forecast, unser Plan. Lass uns über Sprint Goal und Prioritäten sprechen – wir organisieren den Weg dorthin.“

18) Häufige Missverständnisse zur Prüfung

• „Open Book = locker“ – Zeit ist der wahre Gegner. Nachschlagen lohnt nur bei Begriffspräzision.
• „Auswendiglernen reicht“ – in PSM I sind viele Fragen konzeptuell. „Warum“ schlägt „Was“.
• „Es geht um Tools/Story Points“ – PSM I bleibt framework-zentriert. Tools sind optional, nicht prüfungsrelevant.

19) Abschließende Checkliste vor dem Start

• Scrum Guide (englisch) mindestens 3–5× aktiv gelesen.
• Scrum Open mehrfach 100 % erreicht (plus PO Open/Nexus Open für Schärfe).
• Deine Top-10 Irrtümer inkl. Korrektur schriftlich festgehalten.
• Klarheit über Commitments zu den Artefakten.
• Klarheit über Accountabilities.
• Examenstaktik parat: Pacing, Markieren, Suche, Priorisierung.
• Ruhe. Atmen. Loslegen.

20) Epilog – warum 98 % nicht das Ziel sein müssen (und doch möglich sind)

Eine sehr hohe Punktzahl ist ein schönes Nebenprodukt. Wichtiger ist, dass du nach der Prüfung mit dem Vertrauen rausgehst, in echten Situationen die richtigen Gespräche anstoßen zu können: über Ziele statt Tickets, Qualität statt Tempoillusion, Lernen statt Schuld. Genau das misst PSM I zwischen den Zeilen.

Viel Erfolg – und vor allem viel Freude an echter, gelebter Agilität.