CSM common mistakes
CSM · Understand the traps and how to avoid them.
Answering scenario questions from personal workplace experience instead of from the Scrum Guide - picking options that sound sensible ('the manager approves the Sprint goal', 'the team reports status to the PMO') because that is how their own organisation works.
Experienced practitioners have strong habits from non-Scrum or partially-Scrum environments, and the exam deliberately offers plausible 'org-chart' distractors that match those habits.
What to do instead
Answer only as 'according to the Scrum Guide'. Before selecting, scan every option for the words manager, assign, approve, report, enforce, sign-off - those are almost always wrong, because the guide's answer is usually self-management plus transparency.
Mixing up the three empirical pillars and the five Scrum values - e.g. choosing 'adaptation' for a scenario that describes information being hidden or misrepresented, or treating the values as aspirational rather than as the basis for the pillars.
The pillars are described in one short paragraph and candidates skim it, then pattern-match on the word 'inspect' or 'improve' rather than on what the scenario actually describes.
What to do instead
Learn one trigger word per pillar: transparency = visible/agreed/shared standard; inspection = frequent check against a goal; adaptation = change course when the check shows deviation. Map each of the five values to the behaviour it enables (e.g. openness enables transparency, courage enables adaptation).
Selecting answers in which the Scrum Master assigns work, sets priorities, approves decisions, or is held accountable for the team's delivery - effectively treating the Scrum Master as a team lead or project manager.
Candidates carry over the idea that someone must be 'in charge', and the Scrum Master is the person they associate with process authority.
What to do instead
Memorise the Scrum Master's accountabilities as coaching and enablement only: establishing Scrum as defined in the Guide, helping the team and organisation improve practices, removing impediments to the team's progress, and ensuring events happen and stay within timebox. If an option has the Scrum Master directing the work, eliminate it.
Misplacing Product Owner authority - believing the Product Owner writes all the items, must attend the Daily Scrum, owns or dictates the Sprint Backlog, or that Developers cannot change the Product Backlog.
The boundary between 'what' (Product Backlog) and 'how' (Sprint Backlog) is the single most confused line in the guide, and both backlogs are covered by similar-sounding options.
What to do instead
Hold two anchors: the Product Owner is the only accountable person for maximising product value and for Product Backlog content, ordering and transparency; the Developers are accountable for the Sprint Backlog and for adapting their plan daily. The Product Owner may attend the Daily Scrum but is not required to and does not run it.
Treating the Daily Scrum as a status meeting - choosing options where Developers report to the Scrum Master or Product Owner, answer the three traditional questions, or where solving a problem during the event is 'out of scope'.
The three questions were widely taught and used for years and are still repeated in most workplace practice; candidates also import the stand-up-as-reporting ritual.
What to do instead
Remember the 2020 wording: a 15-minute event for the Developers, for the Developers, to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. It is a planning and synchronising event, not reporting; the format is up to the Developers and detailed discussion is legitimately deferred to after the event.
Swapping the purposes of the Sprint Review and the Sprint Retrospective - saying the Review is where the team improves its process, or that the Retrospective is where stakeholders inspect the Increment and the Product Backlog is adjusted.
Both events happen at the end of the Sprint and both involve 'looking back', so candidates match on the shared word instead of on the object being inspected.
What to do instead
Anchor on the object: Review inspects the product (Increment, Product Backlog, market conditions) with stakeholders to decide future adaptation; Retrospective inspects the way of working (people, process, tools, Definition of Done) for the Scrum Team only. If stakeholders appear in the option, it is a Review; if only the Scrum Team appears, it is a Retrospective.
Getting the timeboxes wrong, especially the halving rule for shorter Sprints, or inventing fixed durations (e.g. 'Sprint Planning is always eight hours', 'Daily Scrum is 15 minutes per Developer', 'a Sprint is always two weeks').
Candidates learn a single number or a typical two-week example and fail to generalise it to the proportional relationship for a one-month Sprint.
What to do instead
Memorise the maximum for a one-month Sprint and halve for shorter Sprints: Planning 8h, Review 4h, Retrospective 3h, Daily Scrum a fixed 15 minutes, and the Sprint itself no longer than one month. Shorter Sprints usually mean proportionally shorter events, not the same durations.
Treating the Definition of Done as optional, as a document owned by the Product Owner or quality department, or as something that can be waived when the team is under pressure.
In real organisations the DoD is often an informal checklist or a QA gate, and the guide's rule that the team must create one if the organisation has none is commonly overlooked.
What to do instead
Fix the rule: if the organisation's standard exists, all Scrum Teams follow it as a minimum; if not, the Developers must create one. Work that does not meet the DoD is not an Increment and goes back to the Product Backlog. The Scrum Team uses the DoD to create transparency; weakening it destroys that transparency.
Equating the Increment with a release - believing each Sprint must produce a release, that an Increment only exists after deployment, or that several Increments cannot exist within one Sprint.
'Usable' is misread as 'shipped', and candidates conflate the artefact with the delivery activity that is optional and often governed by the organisation.
What to do instead
Learn the Increment as the sum of the completed, verifiable work that meets the Definition of Done and is a concrete step toward the Product Goal. An Increment is created whenever a Product Backlog item meets the DoD - so several may exist in one Sprint - and delivery to stakeholders may happen at any time and is not required each Sprint.
Treating Product Backlog refinement as a formal event with a fixed attendee list and timebox, or assuming the Product Backlog is frozen and unchangeable once a Sprint begins.
Refinement is widely run as a recurring ceremony in practice, and 'protect the Sprint' intuition suggests the backlog should be locked, which the guide does not say.
What to do instead
Refinement is an ongoing activity, not one of the five events, and its time and attendees are decided by the Scrum Team. The Product Backlog is a living artefact: it is updated continuously during the Sprint, and the Sprint Goal is the element that gives the team focus - not a freeze on the backlog.