The 10 most common traps in Scrum exams

After writing hundreds of practice questions, one pattern keeps coming back. Candidates rarely fail for want of reading. They fail because they answer with traditional management reflexes. Here are the ten costliest traps. ## 1. Believing the Scrum Master runs the team The Scrum Master does not assign tasks, does not approve work and does not settle technical decisions. They are accountable for the team's effectiveness, not for commanding it. Any answer where they "decide in place of" someone is nearly always wrong. The line with the Product Owner deserves a guide of its own: who actually decides what. ## 2. Thinking a Sprint can be extended Never. A Sprint's length is fixed. If the work is unfinished, it goes back to the Product Backlog. A Sprint does not stretch and does not shrink. ## 3. Confusing the Sprint Goal with a list of items The Sprint Goal is the commitment; the selected items are a forecast. Scope can be renegotiated mid-Sprint without touching the Goal. Finishing every item without reaching the Goal is not a success. The subject deserves a guide of its own: Product Goal and Sprint Goal. ## 4. Believing the Sprint Review is a demo It is a collaborative working session where the result is inspected and the Product Backlog is adapted. It is neither a one-way presentation nor a formal delivery sign-off. ## 5. Waiting for the Sprint Review to release An Increment can be released at any point in the Sprint, as soon as it meets the Definition of Done. The Review is not a gate in front of delivering value. ## 6. Lowering quality under pressure Quality does not drop and the Definition of Done does not soften to "finish on time". Work that does not meet the DoD is simply not an Increment. ## 7. Planning a "Sprint 0" or a stabilisation week Scrum knows neither. From the first Sprint, the team aims at a usable Increment. A recurring need to stabilise reveals a Definition of Done that is too weak. The trap keeps coming back in the PSD I. There, the absence of an architect and of a preliminary phase is among the most tested points. ## 8. Multiplying Product Owners or backlogs One product means one Product Backlog and one Product Owner, even with several teams. The Product Owner is a person, not a committee. ## 9. Turning the Daily Scrum into a progress report The Daily belongs to the Developers. It exists to inspect progress toward the Sprint Goal and to adapt their plan. It is not a checkpoint for the Product Owner or for management. ## 10. Answering "what works in real life" rather than what Scrum says This is the subtlest trap. The exam assesses your understanding of the Scrum framework, not the compromises your current organisation makes. If your company does otherwise, that does not make its practice correct for exam purposes. ## How to guard against them For every situational question, test the answer against three criteria. Does it preserve the team's self-management? Does it maintain transparency? Does it protect the Sprint Goal? An answer ticking all three is nearly always the right one. That reflex is built under real conditions rather than on a page. The four-step method for the PSM I sets out the preparation rhythm that makes it hold on the day.