PSPO I Practice Questions: Learn the Scrum Guide Ideas They Test

Practice questions pay off when you treat each one as a short lesson in the Scrum Guide, not as a score to chase. The PSPO I assessment from Scrum.org asks 80 questions in 60 minutes and expects 85%, so a wrong answer you cannot explain is the real cost. This guide shows the ideas the questions keep returning to and how to learn from every miss.

What should one practice question teach you besides the right answer?

Most candidates finish a set, look at the percentage and move on. That wastes the best part of the exercise. A well-built question about Scrum hides a single sentence of the Scrum Guide behind a realistic situation, and the useful skill is recognising which sentence it is. If you can name it, you can answer every variation of that question, however the wording changes. If you can only remember that option C was correct, a reworded question sends you back to guessing.

Scrum.org says on its assessment page (checked November 2026) that many questions cover the Product Owner accountabilities described in the Scrum Guide and the application of Scrum from your own experience. That mix explains why practice has to do two jobs. It has to push you back to the text of the guide, and it has to test whether you can apply that text when a scenario is messy and the workplace habit you know points the other way.

The facts that frame the practice

Item	Detail
Assessment	Professional Scrum Product Owner I (PSPO I), Scrum.org
Questions	80
Time	60 minutes
Question types	Multiple choice, multiple answer and true/false, according to Scrum.org
Score needed	85%
Price	$200 USD for each attempt

At 85% of 80 questions you need 68 correct, so you can afford twelve misses. Twelve is not many when a single misunderstanding can sink three or four questions at once. That is the argument for learning ideas rather than answers: one corrected idea repays you several times in the real sitting.

The rest of this page walks through the ideas that recur, the answer shapes that catch people out, and a method for reviewing a result. The scenarios below are invented for illustration. They are not Scrum.org's questions and they are not a prediction of what you will see.

How does the assessment test product value?

The Scrum Guide gives the Product Owner one headline accountability: maximizing the value of the product resulting from the work of the Scrum Team. The guide adds that the Product Owner may delegate the work but stays accountable. A large share of the product questions are variations on that sentence, and the stems tend to sound like a manager's problem rather than a Scrum one.

Take an invented situation. A team has finished a feature that users barely touch, and the Developers ask what to do next. The tempting responses are all activities: hold a longer review, add a second approval step, write more detailed requirements. The answer that fits the Scrum Guide is about value and evidence. The Product Owner looks at what the outcome tells the team, adjusts the Product Backlog and moves toward the Product Goal. Value is judged by what the product does for people, not by how many items left the backlog.

Reading a value question

Four checks help, and you can run them on any practice question in a few seconds.

• Whose accountability is this? If the stem is about maximizing value, the Product Owner is accountable even when others do the work.
• Is the option about output or outcome? Counting features, tasks or velocity is output. The guide cares about the value of what is delivered.
• Does the option move toward the Product Goal? The guide describes the Product Goal as a future state of the product, the long-term objective the team plans against.
• Is a new role or document doing the work? Scrum does not add one to solve a value problem.

Scrum.org's focus areas place Product Vision, Product Value, Forecasting and Release Planning, Business Strategy, Stakeholders and Customers, and Product Backlog Management under the heading Managing Products with Agility. When you review a value question you got wrong, ask which of those six topics it belonged to. Misses tend to cluster in one, and the cluster tells you what to study next.

Who owns the Product Backlog when stakeholders push?

This is the most reliable theme in the assessment, and it is where workplace habits do the most damage. In many organisations a sponsor reorders priorities in a meeting, a department adds its requests directly to a team's list, and a committee decides what gets built. Scrum describes something narrower. The Product Owner is one person, not a committee. The Product Backlog is that person's accountability, and the guide states that those who want to change it can do so by trying to convince the Product Owner.

The guide adds a sentence that makes the other half of the theme: for Product Owners to succeed, the whole organization must respect their decisions. A practice question may build a scenario in which a senior stakeholder insists on a change. The answer that survives the Scrum Guide does not give in, and it does not shut the stakeholder out either. The Product Owner listens, weighs the request against value and the Product Goal, and decides.

The picture below lines up six places where a familiar workplace answer and the Scrum Guide part company. Use it as a self-test: cover the right-hand column and say who owns each item before you look.

Accountability is not the same as doing all the work

Candidates often overcorrect. Having learned that the Product Owner owns the backlog, they pick answers where the Product Owner writes every item, sizes every item and decides how the Developers build. The guide pulls the other way. Product Backlog refinement is the act of breaking down and defining items, and the Developers who will do the work are responsible for the sizing. The Sprint Backlog is a plan by and for the Developers. A Product Owner who assigns the Sprint's tasks has taken something that belongs to the Developers.

So a good habit for ownership questions is to write three short labels beside the stem: Product Owner, Developers, Scrum Master. Then decide which label the action belongs to. The correct option nearly always puts the action under the right label, and several wrong options give the right action to the wrong person.

Where the Scrum Master fits

The guide lists, among the Scrum Master's services to the Product Owner, helping find techniques for effective Product Goal definition and Product Backlog management. A Scrum Master who edits the backlog, or who decides priorities because the Product Owner is busy, is not doing this. In practice questions, an option that moves the Product Owner's decision to the Scrum Master is a polite way of being wrong.

What is a Sprint Review question really asking?

The Sprint Review has a short purpose statement in the guide: to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents its results to key stakeholders and progress toward the Product Goal is discussed. Two further sentences in the guide create most of the exam traps. It calls the Sprint Review a working session that the team should avoid limiting to a presentation, and it says the Sprint Review should never be considered a gate to releasing value.

Read with those lines in mind, the pattern of wrong options becomes easy to spot. Here is an invented stem: a team is nervous because stakeholders have never seen the work, and someone proposes that nothing should be released until the Sprint Review has approved it. The tempting answers treat the event as an approval ceremony, a demonstration to a customer who signs off, or a status report to a manager. The answer that fits describes a conversation: stakeholders and the team look at what was achieved, discuss what has changed in the market or the product, and decide what to do next, which often means adjusting the Product Backlog.

Questions that mix the Review with other events

Some questions place the Sprint Review beside another event and ask which activity belongs where. Keep the purposes apart:

• The Sprint Review looks at the product and what to do next, with stakeholders present.
• The Sprint Retrospective looks at how the Scrum Team worked and what to improve. Its subject is the team, not the product.
• Sprint Planning decides what the Sprint will deliver and how, and it produces the Sprint Goal along with the Sprint Backlog.
• The Daily Scrum is for the Developers to adapt their plan toward the Sprint Goal.

An option that places a stakeholder conversation about the roadmap in the Retrospective, or team process feedback in the Review, is mixing subjects. You will not memorise your way past this. You will recognise it once you have explained, aloud, what each event is for.

Stakeholders are not a verdict

The Product Owner may represent the needs of many stakeholders in the Product Backlog, according to the guide. Representing needs is different from obeying requests. In a practice scenario where two stakeholder groups want opposite things, no option should end with the louder group getting its way. The expected reasoning is that the Product Owner weighs both needs against value and the Product Goal, makes the ordering visible and explains it. Transparency is the answer to disagreement, not a vote.

How does Done decide whether work counts?

Done is short to define and surprisingly easy to get wrong in a question. The guide describes the Definition of Done as a formal description of the state of the Increment when it meets the quality measures required for the product. It also says an Increment is born the moment a Product Backlog item meets the Definition of Done, and that work cannot be considered part of an Increment unless it meets it. Items that fail it cannot be released or even presented at the Sprint Review.

That last sentence is the source of many scenarios. Picture an invented team that has built a feature but not finished its testing, with the Sprint ending tomorrow. Tempting answers: show it at the Review anyway and mark it as nearly Done, release it with a promise to test later, or count the work toward the team's progress. The guide's reasoning is flat. Unfinished work does not belong to the Increment, so it goes back to the Product Backlog, where the Product Owner decides what happens next.

Who does what around Done

Holding to the Definition of Done is part of what the guide makes the Developers accountable for, as a way of building quality in. That means a Product Owner who pressures the team to call something Done before it meets the definition is asking for something Scrum does not allow, and an answer that agrees to it is wrong. Equally, an answer that has the Product Owner quietly lower the quality bar to hit a date contradicts transparency, which is one of the three pillars of empiricism the guide names.

Two more wrinkles appear in practice. A question may ask who decides whether an item is Done. The honest answer from the guide is that the item is Done when it meets the Definition of Done, which makes the decision a matter of the agreed standard, not of someone's opinion on the day. And a question may ask what happens when the standard is too weak. The Scrum Team, through its events, inspects and adapts. The Sprint Retrospective is where a team improves how it defines quality.

Done versus ready

Candidates sometimes confuse Done with the idea of a ready backlog item. The guide says that items the Developers can finish within one Sprint are deemed ready for selection in Sprint Planning. Ready is about entry to a Sprint and carries no formal gate; Done is the exit standard for an Increment. If an option demands that every item be fully specified before it can enter a Sprint, it is treating a refinement habit as a rule.

What do the tempting wrong answers have in common?

After a few dozen practice questions the wrong options start to look alike. They are rarely absurd. They are answers that would work in a plain project, in a command-and-control company or in a loosely agile one, and that is the trap. The table below groups the shapes you will meet. It is a study aid built from the guide's text and the way scenario questions are commonly constructed, not a description of how Scrum.org designs its assessment.

Answer shape	Why it tempts	How to test it
A new role, document or phase appears	It sounds like good governance	Search the guide for it; if the guide never mentions it, drop it
The right action goes to the wrong owner	The action is correct, so the option reads well	Label the stem Product Owner, Developers, Scrum Master and match the action
Someone senior approves or decides	It mirrors how many workplaces run	Ask whether the guide gives that person any authority over the item
The option is true but not what was asked	It states a real Scrum fact	Reread the last sentence of the stem and answer exactly that
The option waits for a future event	Patience feels safe	Check whether inspection and adaptation could happen sooner without breaking Scrum
The option measures activity	Numbers feel objective	Ask whether it tells you anything about the value delivered

The true-but-irrelevant option

This is the pattern that costs strong candidates the most. You know Scrum well, so you see a statement you know to be correct and choose it. Then you notice later that the stem asked for the Product Owner's action and the statement described the Developers. Make it a rule to restate the question in your own words before reading the options. A restated question is hard to answer with a correct but irrelevant sentence.

Absolute words

Words such as always, never, only and must deserve a pause rather than a rule. The guide does contain real absolutes: only the Product Owner has the authority to cancel a Sprint, and a Sprint could be cancelled if the Sprint Goal becomes obsolete. An absolute that matches a sentence of the guide is a clue to the right answer. An absolute that comes from your instinct about management is the clue to a wrong one. The test is always the same: find the line in the guide.

Multiple-answer questions

Scrum.org lists multiple answer among its question types, and these deserve separate practice because the temptation is to stop at the first correct option. Judge each option on its own against the stem, and do not decide by counting how many you expect to be right. Practising the format, not only the content, removes a source of surprise on the day.

How do you review a practice result so the next attempt is better?

A short, careful review of each attempt beats an extra attempt taken without one. Scrum.org's page says you do not receive the specific questions you got right or wrong in the real assessment, only a performance breakdown by Professional Scrum Competencies. That makes your own practice review the only place where individual questions get dissected, so do it carefully while it is available.

A six-step review

1. Sort every miss. Label it as a knowledge gap, a misread stem or a guess. They need different fixes, so keep them apart.
2. Find the guide line. Locate the sentence in the Scrum Guide behind the correct answer and read the paragraph around it, not only the sentence.
3. Name the owner. Say whether the action belongs to the Product Owner, the Developers or the Scrum Master, and whether the whole Scrum Team shares it.
4. Reread your correct answers. A right answer chosen by luck hides the same gap as a wrong one. If you cannot explain a correct answer, count it as a miss.
5. Write your own reason. One sentence on why each wrong option fails. This is the step that turns recognition into understanding.
6. Return after a gap. Take a fresh set only once you have reread the relevant part of the guide, and compare the same categories of miss across attempts.

Reading patterns across attempts

Keep a simple tally with three columns: the focus area, the kind of miss and the guide line. After three or four sets, patterns appear. If most of your misses are misread stems, more studying will not help; slower reading will. If they cluster in Managing Products with Agility, the area that covers value, forecasting and stakeholders, go back to the evidence and product ideas and not to the events. If they are all ownership mix-ups, redraw the three labels from the earlier section until the split feels natural.

What a good score does and does not say

A strong score on one set tells you that you handled that set. It says little about the next one if the questions test different sentences of the guide. Look for a steady score across several different sets, a result at or above the 85% pass mark, and the ability to justify answers without peeking. Because the real assessment gives you 60 minutes for 80 questions, also notice whether your review habits survive a faster pace. If you only review well when untimed, practise one set under the clock and see which reflexes remain.

Where do practice questions fit alongside the Scrum Guide and the open assessments?

Scrum.org says attending a course is not required but strongly recommended, and it points candidates to its free Scrum Open and Product Owner Open assessments as practice. It also links a suggested reading list from the assessment page. The Scrum Guide itself is free, short and the thing the questions grow from, so read it before you drill. You can find it on Scrum.org's Scrum Guide page, and the free Product Owner Open assessment gives a first read on where you stand.

Think of the three as stages. The guide gives you the language, an open assessment shows how that language is tested, and further practice builds range and speed. Skipping the first stage is the classic error: candidates who drill questions without reading the guide end up memorising the answers to scenarios, which fails when the scenario changes.

The PSPO I practice exam gives you a wider pool of scenarios to take through the six-step review, and the PSPO I sample questions let you try the format first. Neither replaces the Scrum Guide, and neither should be read as a copy of the questions Scrum.org uses.

Signs you are ready to book

• You clear the pass mark on different sets, not the same set repeated.
• You can state in a sentence what each Scrum event is for, without notes.
• Your misses are mostly misread stems, which are fixable in the moment, not whole topics you have not studied.
• You can explain why each wrong option fails in a handful of recent questions.

Each password is valid for one attempt and has no expiry date, so there is no calendar pressure to rush. Waiting a week to close a visible gap costs nothing. Scrum.org's page describes the credential as a lifetime certification with no annual renewal fee, so the downside of waiting until you are ready is small.

Three ideas to carry into the real assessment

If practice teaches you only three things, make them these. First, accountability has an owner: the Product Owner for value and the Product Backlog, the Developers for the Sprint Backlog and for quality, the Scrum Master for helping everyone understand Scrum. Second, events are for inspection and adaptation, not for approval, and the Sprint Review in particular is a working session and never a release gate. Third, work that does not meet the Definition of Done is not part of an Increment, whatever the date says.

Behind all three is one habit: go back to the Scrum Guide for the line that settles the question. Candidates who do that during practice do it faster on the day, and they stop being drawn to answers that sound like good management and are not Scrum. Practice questions then serve their real purpose, which is to show you where your picture of Scrum still differs from the guide, one scenario at a time.

The fee, the pass mark and the format are on Scrum.org's PSPO I assessment page, which is the place to confirm anything before you book.

Frequently Asked Questions

What are PSPO I practice questions, and how do they differ from the real assessment?

They are scenario questions in the style of the Professional Scrum Product Owner I assessment, used to rehearse your reasoning. Scrum.org offers free open assessments for this. The real assessment has 80 questions in 60 minutes with an 85% pass mark and costs $200 USD per attempt, so practice should end with a review, not a score.

How do I know when I am ready to sit PSPO I?

Look for a score at or above 85% across several different practice sets, not one set repeated. You should also be able to say why each wrong option fails and name the Scrum Guide line behind each answer. If most misses are misread stems rather than missing knowledge, slow your reading before you book.

Which topics do the PSPO I questions cover?

Scrum.org groups them into three focus areas: understanding and applying the Scrum framework, developing people and teams, and managing products with agility. Many questions test Product Owner accountabilities from the Scrum Guide and applying Scrum from experience. Product value, Product Backlog management, stakeholders, forecasting and Done come up repeatedly.

Can I retake PSPO I with the same password?

No. Scrum.org states that each password is valid for one attempt only, though it has no expiration date, so you can hold it until you feel prepared. A further attempt needs another password at the per-attempt fee of $200 USD, which is one reason to review practice results carefully first.

Can I pass PSPO I with practice questions alone?

It is risky. Scrum.org says a course is not required but strongly recommends one, and it points candidates to the Scrum Guide, a reading list and its free open assessments. Practice questions work best after you have read the guide, because they show where your understanding still differs from it.

Select ratingPoorOkayGoodGreatAwesome

Average: 4.8 (656 votes)