PSM common mistakes
PSM · Understand the traps and how to avoid them.
Treating the Sprint Retrospective as the only event where inspection and adaptation of the process happens, and answering questions about improving the way of working by pointing only to the Retrospective.
Candidates memorise the event list and map each event to one purpose, missing that the Daily Scrum inspects progress toward the Sprint Goal and adapts the plan, and that the Sprint Review adapts the Product Backlog. This single-purpose mapping feels tidy and is reinforced by the familiar 'Retro = process improvement' slogan.
What to do instead
For each event, write down three things: what is inspected, what is adapted, and who attends. Then practise scenarios where a team discovers mid-Sprint that its plan is wrong and identify which event is the correct container for that adaptation. Explicitly separate adapting the plan (Daily Scrum), adapting the product (Sprint Review), and adapting the process (Retrospective).
Describing the Scrum Master as the person who assigns tasks, resolves impediments on the team's behalf, or decides how the team will do the work.
Real-world experience often shows Scrum Masters acting as coordinators or proxies for management, so candidates answer from observed practice rather than from the framework. The word 'Master' also suggests authority over the team.
What to do instead
Rehearse the accountability statement: the Scrum Master causes the removal of impediments, coaches self-management, and ensures the events happen and are productive, but does not own the team's decisions. For every scenario, ask 'who decides this?' and check the answer against the accountabilities: Developers decide how, Product Owner decides what and order, Scrum Master decides process effectiveness.
Treating the three questions (what did I do yesterday, what will I do today, any impediments) as a mandatory structure of the Daily Scrum.
The three questions are widely circulated in training material and blogs, so candidates assume they are prescribed. The current Scrum Guide instead describes the Developers inspecting progress toward the Sprint Goal and adapting the Sprint Backlog, with the structure left to the Developers.
What to do instead
Learn the purpose and constraints of the Daily Scrum (15 minutes, for the Developers, held every working day at the same time and place, may be restructured as long as the purpose is met) and treat any specific question set as one optional technique. When a question asks whether a format is required, the answer is that the Developers choose it.
Answering questions about 'Done' by saying it is defined by the organisation's quality standards only, or that the Definition of Done is optional if the team is mature.
Candidates conflate organisational standards with the Definition of Done and treat maturity as a reason to relax formality. They also miss that if the organisation has no Definition of Done, the Scrum Team must create one.
What to do instead
Memorise the rule chain: the Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product; if the organisation's standards exist they are the minimum; if not, the Scrum Team creates one; multiple teams on one product must share one. Then practise the consequence: work that does not meet the Definition of Done is not part of the Increment and does not get presented at the Sprint Review as done.
Choosing 'the Scrum Master facilitates the Retrospective' or 'the Product Owner runs the Sprint Review' as the correct answer when the question asks who is accountable for the event's outcome.
Facilitation and accountability get blurred because the Scrum Master often does facilitate and the Product Owner often presents. Candidates pick the person who visibly runs the meeting rather than the person accountable for the event's purpose.
What to do instead
Build a two-column table: event, accountable party, and typical facilitator. Note that the Sprint Review's purpose is to inspect the outcome and determine future adaptations, with the Product Owner accountable for optimising value; the Retrospective's purpose is to plan ways to increase quality and effectiveness, and the Scrum Master ensures the event takes place and is positive and productive. Answer 'who is accountable' from the table, not from who speaks most.
Explaining self-management as 'the team decides everything without any boundaries', and rejecting options where the Product Owner sets the Sprint Goal or where organisational policies constrain the team.
The word 'self-managing' invites an absolute reading. Candidates overcorrect from command-and-control experience and assume any external direction contradicts self-management.
What to do instead
Define self-management precisely: the Scrum Team is self-managing in that it internally decides who does what, when, and how. The Product Owner remains accountable for effective Product Backlog management and the Sprint Goal; the organisation provides the environment and policies. Practise boundary questions: which decisions belong inside the team, which belong to the Product Owner, and which belong to the organisation.
Answering coaching scenarios with directive advice, such as telling the team exactly which practice to adopt, rather than designing an intervention that raises the team's own awareness and capability.
Exam items describe a struggling team and the candidate's instinct is to solve the described problem. Directive answers often sound helpful and concrete, which makes them attractive.
What to do instead
Apply a simple filter to every option: does it build the team's capacity to solve the problem, or does it solve the problem for them? Prefer options that ask powerful questions, create safety, make the impediment visible, or experiment. Reserve directive answers for genuine teaching moments, safety or compliance issues, and cases where the team explicitly asks for direction.
Treating velocity as a commitment or a performance target, and forecasting release dates by dividing total remaining work by an average velocity without stating assumptions or a range.
Velocity is the most familiar metric in practice and is often used in organisations as a target. Candidates carry that usage into the exam and select answers that imply a fixed date or a single-point forecast.
What to do instead
Reframe velocity as an observed, team-specific, past-facing indicator used only for forecasting within a stable context. When a question involves a release date, look for answers that express a probabilistic range, state the assumptions, and update the forecast as data arrives. Reject any option that treats velocity as a commitment, compares teams, or converts it into an individual productivity measure.
Treating the Product Backlog as a static, fully specified list and treating refinement as an optional meeting rather than ongoing work of decomposition and reordering.
Candidates learn the artefact definition and stop there, missing the ongoing activity. They also confuse the Product Backlog with a Sprint Backlog or a requirements document and assume items must be complete before work starts.
What to do instead
Describe the Product Backlog as an emergent, ordered list that is never complete; the Product Owner is accountable for its content, availability, and ordering, and the Scrum Team decides how and when to refine. Practise distinguishing the Product Backlog (what and why, ordered by value) from the Sprint Backlog (the selected items plus the plan, owned by the Developers).
Answering stakeholder questions by having the Scrum Master or Developers manage stakeholder expectations directly, or by treating the Sprint Review as a status presentation rather than a working session.
Status-meeting habits are strong, and candidates assume stakeholder management is a separate communications duty rather than part of the Product Owner's accountability for value and Product Backlog management.
What to do instead
Learn the Sprint Review as a working session where the Scrum Team and stakeholders inspect the Increment, discuss the Product Backlog, and collaborate on what to do next; the Product Owner is accountable for engaging stakeholders and optimising value. For each stakeholder scenario, ask whether the proposed action changes the product or merely reports on it, and choose the option that invites collaboration and informs the Product Backlog.