Die Scrum-Mythen, die in den Prüfungen PSM I, PSPO I und CSM die meisten Punkte kosten, sind Gewohnheiten, die nach Scrum klingen, aber nicht im Scrum Guide 2020 stehen: Story Points, Velocity, ein Sprint 0, eine 10-%-Regel für das Refinement oder ein Scrum Master, der das Team führt. Scrum-Prüfungsfragen basieren auf dem Guide, deshalb ist eine Antwort, die sich daran orientiert, wie dein Unternehmen Scrum lebt, oft genau die Falle. Unten findest du zehn Mythen, die jeweils richtige Aussage und den Grund, warum Prüfer sie einsetzen.
Warum Scrum-Prüfungsfragen auf Mythen aufbauen
Der Scrum Guide 2020 umfasst nur etwa 13 Seiten, daher können die Prüfungsautoren dich nicht zu obskuren Details abfragen. Stattdessen testen sie, ob du das Framework von den Praktiken unterscheiden kannst, die Menschen darum herum ergänzen.
Der Zeitdruck verschärft das. Du hast pro Frage wenig Zeit, und eine vertraut klingende Antwortoption ist verlockend, wenn die Uhr läuft.
| Prüfung | Fragen | Zeit | Zum Bestehen |
|---|---|---|---|
| PSM I (Scrum.org) | 80 | 60 Minuten | 85 % |
| PSPO I (Scrum.org) | 80 | 60 Minuten | 85 % |
| CSM (Scrum Alliance) | 50 | 60 Minuten | 37 richtige (74 %) |
Eine nützliche Faustregel: Wenn der Scrum Guide es nicht sagt, ist es kein vorgeschriebener Teil von Scrum.
10 Scrum-Mythen und was der Scrum Guide tatsächlich sagt
Mythos: Story Points, Velocity und User Stories gehören zu Scrum
Realität: Der Scrum Guide erwähnt weder User Stories noch Story Points, Velocity oder Burndown-Charts. Das sind ergänzende Praktiken, die viele Teams nutzen, aber Scrum verlangt nur ein Product Backlog mit Einträgen, ein Sprint Backlog und Increments, die die Definition of Done erfüllen.
Warum es eine Falle ist: Diese Begriffe sind im Arbeitsalltag so verbreitet, dass sie offiziell wirken. Achte auf Optionen wie „the Scrum Master tracks velocity“ oder „items must be written as user stories“. Wenn eine Antwort eine ergänzende Praktik zur Pflicht macht, ist sie fast immer falsch.
Mythos: Der Scrum Master ist der Manager oder Projektleiter des Teams
Realität: Der Scrum Master ist für die Wirksamkeit des Scrum Teams verantwortlich. Das Scrum Team ist ein einziges Team ohne Teilteams oder Hierarchien, und der Guide beschreibt darin keinen Projektleiter und keinen Teamleiter.
Warum es eine Falle ist: Fragen beschreiben oft ein Problem (einen Konflikt, eine verpasste Deadline, eine blockierte Aufgabe) und bieten eine Option an, bei der der Scrum Master Arbeit zuweist oder für das Team entscheidet. Die bessere Antwort lässt den Scrum Master meist coachen, lehren oder ein Hindernis beseitigen, damit das Team das Problem selbst lösen kann.
Mythos: Das Daily Scrum ist ein Status-Meeting für den Scrum Master und den Product Owner
Realität: Das Daily Scrum ist ein 15-minütiges Event für die Developers, das an jedem Arbeitstag des Sprints zur gleichen Zeit am gleichen Ort stattfindet. Sein Zweck ist, den Fortschritt in Richtung Sprint Goal zu inspizieren und das Sprint Backlog anzupassen. Der Guide verlangt nicht, dass der Product Owner teilnimmt, und der Scrum Master führt es nicht als Berichtsrunde durch.
Warum es eine Falle ist: Viele kennen nur tägliche Meetings, in denen alle an eine Führungskraft berichten. Optionen wie „the Product Owner must attend to approve the plan“ oder „the Scrum Master collects status updates“ zielen auf diese Erfahrung ab.
Mythos: Product Backlog Refinement kostet 10 % der Kapazität der Developers
Realität: Refinement ist eine fortlaufende Aktivität und kein Event, und der Scrum Guide 2020 nennt keinen Prozentwert. Die alte Formulierung „in der Regel nicht mehr als 10 %“ wurde 2020 gestrichen.
Warum es eine Falle ist: Ältere Lernmaterialien und ältere Übungsfragen nennen noch die 10 %; in einer aktuellen Prüfung gibt es keine feste Zahl.
Mythos: Im Sprint Review nimmt der Product Owner die Arbeit ab oder gibt sie frei
Realität: Das Sprint Review ist eine Arbeitssitzung, in der das Scrum Team und die Stakeholder das Ergebnis des Sprints inspizieren und entscheiden, was als Nächstes zu tun ist. Es ist kein Freigabe-Gate. Ein Increment entsteht, sobald ein Product Backlog Item die Definition of Done erfüllt, und Increments dürfen schon vor dem Sprint Review an Stakeholder ausgeliefert werden.
Warum es eine Falle ist: „Demo und Abnahme“ ist in vielen Organisationen die übliche Form des Reviews. In der Prüfung ist jede Option verdächtig, die das Sprint Review als einzigen Zeitpunkt für ein Release oder als formelles Abnahme-Meeting darstellt.
Mythos: Teams brauchen einen Sprint 0 oder einen Hardening-Sprint
Realität: Der Scrum Guide erwähnt weder einen Sprint 0 noch Hardening-Sprints. Jeder Sprint soll mindestens ein nützliches Increment hervorbringen, das die Definition of Done erfüllt. Ein Sprint, der dem Setup oder der Stabilisierung früherer Arbeit gewidmet ist, deutet darauf hin, dass die Definition of Done nicht eingehalten wird.
Warum es eine Falle ist: Diese Begriffe sind weit verbreitet, daher kann eine Frage lauten „what should happen in Sprint 0?“, als wäre er real. Die richtige Antwort verweist meist darauf zurück, in jedem Sprint ein fertiges (Done) Increment zu liefern.
Mythos: Der Product Owner kann ein Komitee sein
Realität: Der Product Owner ist eine Person und kein Komitee. Der Product Owner darf die Bedürfnisse vieler Stakeholder vertreten und Arbeit am Product Backlog an andere delegieren, bleibt aber verantwortlich für die Maximierung des Werts und für das Product Backlog Management.
Warum es eine Falle ist: Das ist ein Favorit im PSPO I. Achte auf Optionen, in denen ein Lenkungsausschuss oder mehrere Fachverantwortliche die Verantwortung des Product Owners teilen; der Guide lässt das nicht zu.
Mythos: Unfertige Arbeit darf im Sprint Review gezeigt werden
Realität: Arbeit, die die Definition of Done nicht erfüllt, ist nicht Teil des Increments. Sie geht zurück ins Product Backlog für spätere Überlegungen und kann weder ausgeliefert noch im Sprint Review präsentiert werden.
Warum es eine Falle ist: „Show it anyway so stakeholders can give feedback“ klingt vernünftig und kooperativ. In der Prüfung ist es falsch, weil es den tatsächlichen Stand des Produkts verschleiert und die Transparenz verletzt.
Mythos: Das Sprint Backlog ist nach dem Sprint Planning festgeschrieben
Realität: Das Sprint Backlog gehört den Developers, die für den Plan verantwortlich sind und ihn täglich anpassen, wenn sie mehr lernen. Fest bleibt die Verpflichtung: das Sprint Goal, das einzige Ziel des Sprints.
Warum es eine Falle ist: Fragen werfen Sprint Goal und Sprint Backlog durcheinander. Wenn eine Option sagt, dass nach der Planung nichts mehr hinzugefügt oder geändert werden darf, oder dass nur der Scrum Master das Sprint Backlog aktualisieren darf, ist sie falsch.
Mythos: Teams sind „self-organizing“ und der Scrum Master ist ein „servant-leader“
Realität: Der Guide 2020 sagt, dass Scrum Teams selbstmanagend (self-managing) sind: Sie entscheiden intern, wer was, wann und wie tut. Er beschreibt Scrum Master als „true leaders who serve the Scrum Team and the larger organization“ und ersetzt damit den Begriff „servant-leader“ von 2017. Außerdem spricht er von Verantwortlichkeiten (accountabilities) statt von Rollen.
Warum es eine Falle ist: Die alte Formulierung ist dem Sinn nach nicht ganz falsch, aber Fragen danach, was der aktuelle Guide sagt, belohnen die aktuellen Begriffe. Wenn zwei Optionen ähnlich aussehen, wähle die mit der Sprache von 2020.
So übst du, diese Fallen zu erkennen
- Lies den Scrum Guide zweimal. Lies ihn einmal am Stück für das große Bild und dann ein zweites Mal langsam. Markiere dabei jede Verantwortlichkeit, jede Verpflichtung (Product Goal, Sprint Goal, Definition of Done) und jede Timebox.
- Führe eine Liste mit Signalwörtern. Wörter wie must, always, approve, assign, report oder ein fester Prozentwert hängen oft an der falschen Option. Prüfe, ob der Guide es tatsächlich sagt.
- Übe unter Zeitdruck. Die Antwort am Schreibtisch zu wissen ist etwas anderes, als sie in unter einer Minute zu finden. Probiere eine kostenlose PSM-Probeprüfung mit Zeitlimit auf Scrumdemy (20 Fragen, 20 Minuten) oder die kostenlose CSM-Probeprüfung.
- Lerne die Erklärungen, nicht nur das Ergebnis. Suche zu jeder falschen Antwort den Satz im Guide, der sie klärt. Wenn du dich auf den PSPO I vorbereitest, enthält das PSPO-I-Vorbereitungsquiz von Scrumdemy zu jeder seiner 80 Fragen eine Erklärung.
- Ergänze die offiziellen kostenlosen Tests. Die Open Assessments von Scrum.org (Scrum Open, Product Owner Open, Developer Open) sind kostenlos und im Stil der echten Prüfung geschrieben.
FAQ
Gehören Story Points zu Scrum?
Nein. Der Scrum Guide 2020 erwähnt weder Story Points noch Velocity oder User Stories. Sie sind optionale Praktiken, daher ist eine Prüfungsantwort, die sie zur Pflicht macht, falsch.
Muss der Product Owner am Daily Scrum teilnehmen?
Nein. Das Daily Scrum ist ein 15-minütiges Event für die Developers, um den Fortschritt in Richtung Sprint Goal zu inspizieren. Der Guide verlangt nicht, dass der Product Owner dabei ist.
Ist „servant-leader“ im PSM I noch die richtige Antwort?
Der Guide 2020 hat „servant-leader“ durch „true leaders who serve the Scrum Team and the larger organization“ ersetzt. Wenn eine Frage danach fragt, was der aktuelle Guide sagt, wähle die Formulierung von 2020.
Darf unfertige Arbeit im Sprint Review gezeigt werden?
Nein. Arbeit, die die Definition of Done nicht erfüllt, geht zurück ins Product Backlog und kann weder im Sprint Review präsentiert noch ausgeliefert werden.