CSO (Other exams) common mistakes
CSO · Understand the traps and how to avoid them.
When asked who owns a decision, the candidate answers with a job title ("the Product Owner decides") instead of naming the accountability and its boundary, so answers about the Product Owner, Scrum Master, and Developers blur together.
Candidates memorise role labels from introductory material and never map each accountability to the specific artifact or event it serves, so they default to hierarchy-based thinking rather than the empirical, self-managing model Scrum describes.
What to do instead
Build a one-page matrix of accountabilities: Product Owner for product value and ordering, Scrum Master for the team's effectiveness and Scrum adoption, Developers for creating the Increment and their own plan. For each, write one sentence on what the role decides alone and one on what it must not decide alone, then test yourself by rewriting any title-based answer into an accountability-based one.
The candidate treats the three empirical pillars and the five Scrum values as interchangeable slogans, so when a scenario describes a team hiding bad news, the answer cites "respect" or "courage" rather than transparency and inspection.
Values and pillars are usually studied as vocabulary lists late in preparation, so they are recalled as labels without the causal chain that links transparency to inspection and inspection to adaptation.
What to do instead
Practise a three-step diagnostic for every scenario: what is not visible (transparency), who is checking it (inspection), and what changed as a result (adaptation). Then attach the relevant value that enables each step. Write five short scenarios of your own and label both the pillar and the value, explaining why each label fits.
Faced with a question about a Sprint that is going badly, the candidate proposes cancelling the Sprint or extending it, rather than identifying which event or artifact should trigger inspection and adaptation first.
Cancellation is the most memorable event rule, so it becomes the default answer for any disruption, and the candidate forgets that only the Product Owner can cancel and only when the Sprint Goal becomes obsolete.
What to do instead
Memorise the narrow trigger for cancellation (Sprint Goal obsolete, Product Owner's call) and rehearse the alternative levers: refinement of the Sprint Backlog, Daily Scrum re-planning, a renegotiated Sprint Goal with the Product Owner, and retro-driven process change. For ten disruption scenarios, decide whether cancellation is actually justified and justify the answer in one sentence.
The candidate describes the Daily Scrum as a status meeting where each person reports to the Scrum Master, and describes the Sprint Review as a demo or sign-off gate rather than a working session with stakeholders.
These events resemble ceremonies from traditional project management that candidates have experienced at work, so prior workplace habit overrides the written purpose and they answer from memory of their own team.
What to do instead
For each event, write the purpose, the participants, the timebox, and the output in a single row. Then rewrite your own descriptions replacing every reporting verb with a planning or collaboration verb, for example "the Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog" instead of "each developer reports progress".
The candidate treats the Definition of Done and the Sprint Goal as optional team conventions rather than as commitments attached to specific artifacts, and confuses which artifact each commitment belongs to.
Commitments were added to the Scrum Guide later than the artifacts themselves, so older study material and workplace practice often omit them, leaving candidates with an artifact-only mental model.
What to do instead
Draw the four artifacts with their commitments as paired boxes: Product Backlog with Product Goal, Sprint Backlog with Sprint Goal, Increment with Definition of Done. For each pair, state in one sentence what the commitment provides and who creates it, then explain how a missing Definition of Done affects transparency of the Increment.
When asked how a Scrum Master handles a team that keeps missing its Sprint Goal, the candidate answers that the Scrum Master should direct the team, assign tasks, or escalate to management to enforce compliance.
Candidates conflate servant leadership with passivity and then overcorrect into command-and-control when a scenario shows poor performance, because they lack concrete facilitative interventions to name.
What to do instead
Prepare a list of at least six concrete servant-leadership moves: teaching the purpose of the Sprint Goal, facilitating the retrospective around root causes, coaching the Product Owner on ordering, making impediments visible, shielding the team from interruption, and helping the team self-manage the Sprint Backlog. For each, write the situation it fits and the outcome it produces without taking over the team's decisions.
The candidate answers coaching questions by prescribing a solution for the team ("tell them to adopt pair programming") instead of describing how to help the team discover its own improvement.
Exam scenarios reward influence without authority, but candidates default to the directive advice they would give a colleague, because they have not practised phrasing coaching interventions as questions, observations, and experiments.
What to do instead
Rehearse a coaching pattern: ask what the team has observed, what it has already tried, what it predicts will happen, and what small experiment it will run and review. Rewrite ten directive answers into this pattern and check that each keeps the decision with the team while still naming a specific next step.
The candidate describes impediment removal as personally fixing the problem, or as simply logging it in a list, rather than distinguishing between resolving, facilitating resolution, and teaching the team to resolve it.
Removing impediments sounds like a hands-on task, and candidates rarely consider that the appropriate response depends on whether the impediment is inside or outside the team's control.
What to do instead
Classify impediments by locus of control: within the team (coach the team to resolve it), within the organisation (the Scrum Master removes or escalates it and reports back), and systemic (raise it with management using evidence). For each class, write the Scrum Master's first action, the expected follow-up, and how progress is made visible to the team.
The candidate applies single-team rules directly to multi-team settings, for example assuming one Product Owner per team, one shared Daily Scrum for everyone, or that a scaled framework replaces Scrum rather than building on it.
Scaling content is often studied last and skimmed, so candidates generalise the single-team model and answer scaling questions with the same reflexes, missing questions about alignment, dependency management, and integration frequency.
What to do instead
Study scaling as an extension of the same accountabilities: one product, one Product Backlog, one Product Owner, with teams sharing a Product Goal and integrating frequently. Write down how each Scrum element changes and what stays the same at scale, and practise identifying which problems are structural (dependencies, integration) versus which are simply Scrum done poorly.
The candidate answers timebox questions from memory with approximate numbers, or gives a rule that sounds right but is wrong, such as a fixed Daily Scrum of exactly fifteen minutes regardless of team size or a Sprint Review that is purely a demonstration.
Timeboxes are small factual details that feel low-risk, so they are studied casually and rarely verified, and the errors survive into the exam because the candidate never cross-checks them against the source.
What to do instead
Create a timebox table for a one-month Sprint and derive shorter Sprints proportionally, then verify each entry against the Scrum Guide wording rather than notes. Pair each timebox with its purpose so a wrong number is caught by a mismatch in the surrounding reasoning.