SMP common mistakes
SMP · Understand the traps and how to avoid them.
When the stem says the Developers are stuck, unsure, or disagreeing, the candidate picks the option where the Scrum Master assigns work, sets priorities, or tells the team what to do next - effectively answering as a project manager.
Habit from traditional delivery roles and from easier exams where the Scrum Master is described as 'ensuring' things happen; the word 'ensure' gets read as 'do it myself'.
What to do instead
For any 'team is stuck' stem, eliminate every option that has the Scrum Master deciding content or assigning tasks. Keep only options where the Scrum Master teaches, coaches, facilitates, or asks a question that grows the team's ability to decide. The accountability is the Scrum Team's effectiveness, exercised through influence, not authority.
Treating the Daily Scrum as a status report to the Scrum Master - endorsing the three questions as a mandatory ritual, letting it run past 15 minutes, or having the Scrum Master run it and take notes for stakeholders.
It looks like the most familiar Scrum event and the three questions are widely quoted, so candidates answer from folklore rather than from the event's purpose.
What to do instead
Anchor every Daily Scrum option on purpose: Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog, within a 15-minute timebox, owned by the Developers. The Scrum Master teaches why it matters and ensures it happens, but does not chair or collect output from it.
Mismatching artifacts with their commitments - pairing the Sprint Backlog with the Definition of Done, the Product Backlog with the Sprint Goal, or answering that the Definition of Done is an artifact rather than a commitment.
The commitments were added later and the three pairs are structurally similar, so under time pressure candidates pattern-match on the artifact name instead of recalling the pairing.
What to do instead
Memorise the three fixed pairs and re-derive rather than recall: Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done. If an option reorders a pair, it is wrong regardless of how sensible the sentence sounds.
Choosing options that increase control and predictability - detailed up-front design, a fixed scope commitment for the quarter, phase gates, or a consolidated status dashboard - when the stem describes uncertainty or volatility.
Risk and unpredictability feel safer when locked down, and such options read as 'responsible' and senior, which is exactly how distractors are written.
What to do instead
Test each option against empiricism: does it increase transparency and the ability to adapt, or does it freeze decisions earlier and hide information? In volatile stems the correct option usually shortens feedback loops and exposes reality sooner, even though it feels less controlled.
Using the wrong intervention level - answering 'explain the framework to them' or 'send them the Scrum Guide' when the stem needs coaching, or answering 'ask a powerful open question' when the situation needs immediate, direct action on a blocking organisational problem.
Candidates learn that coaching is the 'advanced' answer and over-apply it, or conversely default to instructing because it feels decisive and fast.
What to do instead
Match the intervention to readiness and risk: teaching when knowledge is missing, mentoring when experience is missing, coaching when the capability exists but the thinking needs unlocking, and direct action when something is actively blocking the team. Ask 'what does this person or team lack - knowledge, experience, or space to think?'
Having the Scrum Master personally remove every impediment, or escalating to management as the first move, rather than helping the team learn to remove what it can and reserving Scrum Master action for impediments outside the team's influence.
Removing blockers feels like visible, measurable service, and escalation feels like strong servant leadership, so both attract candidates over slower capability-building options.
What to do instead
Classify each impediment by who can act: if the team can remove it, coach and let them; if it is organisational, the Scrum Master owns it and works the system. Choose the option that matches the classification in the stem rather than the option that shows the most activity.
Equating value with output - selecting 'increase velocity', 'deliver more story points per Sprint', or 'keep the team fully utilised' as the goal of improvement work, and accepting utilisation-based metrics as evidence of success.
Velocity is the most visible number in Scrum reporting, so it gets treated as the scoreboard, especially in stems where stakeholders are demanding more delivery.
What to do instead
Re-anchor on outcome: value is progress toward the Product Goal and evidence that a customer or business problem moved, not throughput. When an option optimises flow of value to stakeholders it beats an option that optimises the team's output volume.
Answering a multi-team or enterprise-level stem by naming a scaling framework or adding a coordinating layer - a Scrum of Scrums, a release train, a portfolio board - before addressing the underlying Scrum and technical practice problems driving the friction.
Framework names are memorable and feel like the 'professional' answer at scale, and the stems are written to make the coordination artefact look like the missing ingredient.
What to do instead
Diagnose before prescribing: most scaling stems resolve to reducing dependencies, improving the Definition of Done and technical quality, and getting single-team Scrum genuinely working. Prefer the option that removes the cause of cross-team coupling over the option that institutionalises meetings to manage it.
Blurring single-person accountabilities into 'the team decides everything' - saying the Developers set the Sprint Goal unilaterally, that the Product Owner must accept whatever ordering the team prefers, or that the Scrum Master is accountable for the Product Backlog.
Self-management is over-generalised into a rule that nobody holds individual accountability, and the distributed language of the Scrum Guide gets flattened into 'the team owns it'.
What to do instead
Learn the accountability table precisely: one Product Owner accountable for maximising product value and for effective Product Backlog management; Developers accountable for the Sprint Backlog and the Increment; Sprint Goal is a collaborative commitment. Reject options that erase the single accountable person, and reject options that hand that person's accountability to the team.
Treating event timeboxes and the Sprint itself as flexible management levers - extending the Sprint when the work is unfinished, cancelling it because scope changed or stakeholders are unhappy, or skipping the Retrospective under delivery pressure.
In real workplaces these compromises are routine, so they feel pragmatic rather than incorrect, and the stems often supply a sympathetic reason for the exception.
What to do instead
Only the Product Owner can cancel a Sprint, and only when the Sprint Goal has become obsolete - never to protect utilisation or appease stakeholders. Timeboxes are fixed, events may be shortened but not skipped, and a Sprint that ends without a releasable Increment is a transparency signal to inspect, not a reason to extend.