PSPO II common mistakes
PSPO II · Understand the traps and how to avoid them.
On questions about ordering, scope trade-offs, or what to build next, choosing answers where the Scrum Master or 'the Developers' make the call - e.g. 'the team votes on the backlog order' or 'the Scrum Master resolves the priority conflict'.
Candidates carry over habits from team-level training where roles blur into 'the team decides', and from scaled environments where a manager, RTE, or committee visibly does the prioritising. The PO's accountability gets quietly reassigned to whoever is most visible in the scenario.
What to do instead
For every scenario, first name the accountability in the Scrum Guide's own terms: PO = value maximisation and Product Backlog ordering; Developers = how to turn items into an Increment; Scrum Master = effectiveness of the framework. Then check what can be delegated versus what stays accountable - ordering decisions can be informed by anyone but remain the PO's call.
Selecting the answer that allows a Scrum rule to be dropped because the team is busy, distributed, or already communicating informally - e.g. endorsing a cancelled Retrospective, a Sprint Review run as an internal demo with no stakeholders, or a Daily Scrum replaced by chat because 'we talk all day anyway'.
The phrase 'Scrum is a framework, not a methodology' is misread as 'the rules are optional'. Candidates apply a general agile-permission mindset instead of the Guide's distinction between an immutable framework and adaptable practices inside it.
What to do instead
Treat the framework's rules as immutable and only the techniques within them as adaptable. For 'what should the Scrum Master/Product Owner do' items, prefer the option that re-establishes the practice and makes the underlying problem visible, rather than the option that removes the event or rule.
Describing the Product Owner as owning the product vision, business model, pricing, go-to-market and long-term roadmap, or conversely describing the Product Manager as merely a senior Product Owner who orders the backlog.
Many courses collapse the two titles and use them interchangeably, so candidates answer from the vocabulary of their own organisation rather than from the Guide's narrow definition of the PO accountability.
What to do instead
Hold two separate definitions: the PO accountability is maximising value from the Scrum Team's work - Product Backlog ordering, transparency, and effective collaboration. Product management is the broader discipline (vision, strategy, market, stakeholders, economics) that may be held by a Product Manager who delegates the PO accountabilities, or by the same person. Answer according to which concept the question is testing.
Assuming the Product Owner must personally perform every product ownership activity - writing each Product Backlog item, personally running every Sprint Review, being the only person allowed to speak to stakeholders - and rejecting answers that involve delegation.
Candidates convert 'accountable for the Product Backlog' into 'sole author and sole doer'. The accountability is confused with the work, which produces answers that describe an overloaded PO rather than an effective one.
What to do instead
Separate accountability from execution. The PO remains accountable for ordering and value, but may delegate authoring, refinement and stakeholder facilitation to Developers or others, provided the PO keeps the ordering decisions and the transparency. Prefer answers where the PO scales their impact through others over answers where the PO does everything alone.
Picking the option that improves throughput or predictability - velocity increases, fewer carry-over items, more backlog items finished per Sprint, fuller utilisation - when the question is actually asking how to improve value delivery.
Velocity and story-point burn are the most familiar and most easily reported numbers candidates have seen, and much of the preparation material they encounter is estimation-heavy. Output feels measurable, so it feels correct.
What to do instead
Before choosing, ask which variable the option changes: the amount of output or the value of the outcome. For Product Owner items, an option that only increases throughput is usually the distractor; the best answer changes what is being built, for whom, or the order in which it is built.
Treating refinement as a scheduled phase or gate - 'refine all items before Sprint Planning', 'hold a refinement meeting every Wednesday that all Developers must attend', or 'items must meet a Definition of Ready before they can be selected'.
This comes from waterfall phase-gate habits and from scaled-framework descriptions of refinement as a ceremony with a fixed agenda, timebox and attendance list.
What to do instead
Refinement is an ongoing activity, not an event: detail, estimates and order are added continuously and adjusted as understanding grows. No timebox, no gate and no mandated meeting exist in the framework. The people who will do the work provide the sizing; the PO keeps the ordering. Reject answers that create a precondition blocking items from entering the Sprint Backlog.
Answering that the Product Owner should shield the Developers from all stakeholder contact and act as the single point of contact, so the correct response to 'stakeholders keep approaching the Developers directly' becomes 'instruct stakeholders to route everything through the PO'.
'Single point of contact' is a widely repeated phrase that candidates apply as a communication firewall. They conflate accountability for the Backlog with exclusivity of contact.
What to do instead
The PO is accountable for the Product Backlog and its ordering, not for gatekeeping access to the team. Direct collaboration between Developers and stakeholders is encouraged because it improves the shared understanding of needs. Prefer answers where the PO makes that collaboration productive - setting expectations, joining the conversation, feeding the insight back into ordering - over answers that block it.
For conflicting stakeholder demands, choosing escalation or consensus mechanisms - escalate to a steering committee or sponsor, take a vote, let the most senior or loudest stakeholder win - instead of the Product Owner making a value-based trade-off.
In real organisations escalation and consensus are the safest social moves, and the exam's framing ('a key stakeholder insists…') invites a conflict-resolution answer. Candidates answer as a diplomat rather than as the accountable decision-maker.
What to do instead
The PO decides, and decides on the basis of value and evidence, not authority or headcount. Look for the option in which the PO makes the trade-off transparent in the Product Backlog and uses data, experiments or outcome measures to support the decision. Reserve escalation for genuine organisational constraints the PO cannot decide, and be suspicious of any option that hands the decision to a committee.
Using velocity, story points completed, percentage of planned scope delivered, or Sprint burndown as evidence that value was delivered, and describing Evidence-Based Management as a dashboard of these numbers.
Velocity is the most visible and most frequently reported artefact in a Scrum environment, so it becomes the default stand-in for 'value'. Candidates rarely have experience of outcome or impact measurement, so they substitute the metric they know.
What to do instead
Keep planning measures and value measures separate. Velocity is a forecasting tool for the Scrum Team; Evidence-Based Management compares value delivered against investment in the product. When a question asks about value, look for outcome, impact, or behavioural evidence tied to the product, not internal throughput numbers.
Naming a metric without connecting it to the question it is meant to answer - quoting a single favourite metric regardless of context, treating one number as the definition of success, or choosing 'measure more things' when the scenario calls for forming a hypothesis and inspecting the result.
Evidence-Based Management gets reduced to a KPI list during study, so candidates memorise metric names and then pattern-match a familiar term to the scenario instead of reasoning from the question the organisation is trying to answer.
What to do instead
Work the chain explicitly in each scenario: what decision are we trying to make, which Key Value Area does it sit in (current value, unrealised value, time to market, ability to innovate), and which measure would actually inform that decision. Prefer answers that describe an empirical loop - hypothesis, measure, inspect, adapt - over answers that only add reporting.