Try 10 focused PSPO I questions on Developing People and Teams, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | PSPO I |
| Topic area | Developing People and Teams |
| Blueprint weight | 14% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Developing People and Teams for PSPO I. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 14% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Developing People and Teams: Self-Managing Teams
During Sprint Planning, a COO joins after a customer escalation and says: “Move these three Product Backlog items into this Sprint now. Two are still unclear, and I want the Product Owner to assign each item to the strongest Developer.” What is the best Scrum response?
Best answer: C
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: In Scrum, executive pressure does not replace Scrum Team accountabilities. The Product Owner remains accountable for Product Backlog ordering, and Developers decide what they can accomplish in the Sprint and how they will do that work.
This scenario combines two common boundary violations: pressuring the Product Owner to surrender ordering decisions and telling Developers who should do the work. A stakeholder or executive can provide urgent input, and the Product Owner may use that input to reorder the Product Backlog. However, during Sprint Planning, Developers determine what can be selected for the Sprint based on their understanding and capacity, and they decide how to turn that work into a Done Increment.
If two items are still unclear, that affects whether the Developers can confidently select them, but it does not give the COO authority to force them in or assign them. Scrum preserves transparency and collaboration without replacing self-management or Product Owner accountability.
The key takeaway is that urgency can inform decisions, but it does not transfer Scrum accountabilities to managers or stakeholders.
This preserves Product Owner accountability for ordering and Developers’ self-management over Sprint work and execution.
Topic: Developing People and Teams: Self-Managing Teams
After a Sprint Review, the Scrum Team sees that a recently released onboarding change improved trial-to-paid conversion, while a heavily requested reporting feature shows very low usage. Several stakeholders now want faster priority decisions because a release forecast has slipped by two Sprints. Which response is most attractive on the surface but violates Scrum?
Best answer: A
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The tempting mistake is to centralize decisions in the name of speed. In Scrum, the Product Owner remains accountable for Product Backlog management, and Developers remain self-managing about how to do the work. New evidence should inform decisions, not justify bypassing those accountabilities.
This scenario includes real empirical signals: conversion improved, another feature has low usage, and the forecast changed. Scrum expects the Scrum Team to inspect those results and adapt. The Product Owner should collaborate with stakeholders and use the evidence to order the Product Backlog, but accountability for effective Product Backlog management stays with one Product Owner. Developers, in turn, decide how to turn selected work into a Done Increment.
A stakeholder committee reordering the Product Backlog and assigning work may sound faster because it concentrates authority, but it replaces empiricism with command-and-control and weakens self-management. A slipping forecast should increase transparency and adaptation, not shift Product Owner decisions to a committee or turn Developers into assigned resources.
The key takeaway is that efficiency-sounding shortcuts are wrong when they break Scrum accountabilities.
It may sound efficient, but it breaks Product Owner accountability for Product Backlog management and undermines Developers’ self-management.
Topic: Developing People and Teams: Self-Managing Teams
A Scrum Team can design, code, and test features, but it still depends on an external operations specialist to deploy changes to the environment required by its Definition of Done. In the last two Sprints, several selected Product Backlog items were not Done because that specialist was unavailable before the Sprint ended. During Sprint Planning, the Product Owner asks how much can actually be delivered next Sprint. What is the next best step?
Best answer: B
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The team should first make the external dependency visible and use it to create a realistic Sprint forecast. Transparency comes from planning based on what the Scrum Team can actually get to Done, not what it hopes an external specialist will finish in time.
A Scrum Team’s forecast is only transparent if it reflects the real conditions for creating a Done Increment. Here, an external deployment dependency has already prevented selected work from meeting the Definition of Done in prior Sprints, so the next appropriate step is to inspect that evidence during Sprint Planning and adapt the forecast accordingly. The team should select work based on what it can reasonably complete to Done under the current constraint and make that limitation visible to the Product Owner and stakeholders. After that, the Scrum Team can work to reduce the dependency or build the missing capability, often with support from the Scrum Master. Pretending the constraint will disappear, weakening the Definition of Done, or having the Product Owner direct task assignments all reduce transparency rather than improving it.
This preserves transparency by basing the Sprint forecast on the team’s actual ability to produce a Done Increment.
Topic: Developing People and Teams: Self-Managing Teams
After three Sprints, a Scrum Team has released Done Increments. At the latest Sprint Review, customer usage data showed one new onboarding feature increased conversions, while another was rarely used. Sales and Marketing now want different next priorities, and a steering committee asks the Product Owner to publish a fixed six-month scope plan and let departments rank Product Backlog items directly.
Which Scrum Master service best addresses this situation?
Best answer: A
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The Scrum Master helps the Product Owner and organization understand Scrum by promoting empirical product planning and clear accountabilities. Here, Sprint Review evidence should update the forecast, while stakeholder input remains collaboration rather than direct control of Product Backlog ordering.
In Scrum, product planning is empirical, so forecasts should change when Done Increments, customer feedback, and usage data reveal new information. The Scrum Master serves the Product Owner and the organization by helping them understand this approach and by clarifying Scrum boundaries. In this scenario, the steering committee’s request for a fixed six-month scope plan conflicts with empirical planning, and letting departments rank Product Backlog items directly conflicts with the Product Owner’s accountability for effective Product Backlog management. Stakeholders should provide input, constraints, and feedback, but the Product Owner remains accountable for ordering the Product Backlog to maximize value. The key takeaway is to coach adaptation based on evidence, not replace Scrum with committee control or sign-off gates.
This uses Sprint Review evidence to adapt plans while reinforcing Scrum boundaries around Product Owner accountability.
Topic: Developing People and Teams: Self-Managing Teams
During a Sprint, a sales director tells two Developers to stop current work and build a custom report for a major prospect by Friday. He tells the Product Owner, “I control revenue, so I set the priority,” and asks the Scrum Master to make the team comply. The current Sprint Goal is still valuable. What is the best next step?
Best answer: C
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: External authority does not change Scrum accountabilities. The Scrum Master addresses the organizational misunderstanding, the Product Owner remains accountable for value and Product Backlog decisions, and the Developers remain accountable for adapting their Sprint plan.
This scenario is about protecting Scrum Team accountabilities when someone outside the team tries to override them. A sales director can provide important business input, but cannot take over Product Owner or Developers accountabilities.
The appropriate collaboration is:
If the new request makes the Sprint Goal obsolete, the Product Owner may cancel the Sprint. The closest trap is treating stakeholder urgency as authority to assign work inside the Sprint.
This preserves organizational coaching by the Scrum Master, value accountability by the Product Owner, and self-management by the Developers.
Topic: Developing People and Teams: Self-Managing Teams
A new Product Owner is under pressure from sales leaders to promise a fixed feature list for a trade show in 10 weeks. The same leaders also say they should re-order the Product Backlog directly during each Sprint Review because they are closest to customers. What is the best action for the Scrum Master?
Best answer: D
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The Scrum Master serves the Product Owner and organization by helping them understand empirical planning, healthy stakeholder collaboration, and Scrum accountabilities. A transparent forecast and Sprint Review feedback support adaptation, while Product Backlog ordering remains accountable to the Product Owner.
The key concept is that the Scrum Master helps the Product Owner and the organization work within Scrum rather than around it. In this situation, the pressure for a fixed scope and direct stakeholder control of backlog order conflicts with empirical planning and Product Owner accountability. The Scrum Master should coach everyone to use a transparent forecast for the trade show, inspect progress through Done Increments, and use Sprint Reviews to gather stakeholder feedback and adapt plans.
Stakeholders are important collaborators, but they do not take over Product Backlog ordering. The Product Owner remains accountable for maximizing value and for effective Product Backlog management. The closest distractor is the idea of detailed upfront estimation and commitment, which treats a forecast as a certainty instead of using empiricism.
This reinforces empirical product planning, stakeholder collaboration, and the Product Owner’s accountability for Product Backlog ordering.
Topic: Developing People and Teams: Self-Managing Teams
A Scrum Team can complete coding for new checkout features each Sprint, but every Sprint the work waits for a separate testing department and a separate UX group before it can be used. Stakeholders are frustrated that value reaches customers only every few Sprints.
Which response is best?
Best answer: D
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: Cross-functionality enables the Scrum Team to create value each Sprint by having the essential capabilities needed to produce a usable Done Increment. When testing and UX depend on outside handoffs for core work, value is delayed and transparency is reduced.
In Scrum, cross-functionality means the Scrum Team collectively has the skills needed to create value each Sprint. In this scenario, coding is not enough because testing and UX work are essential to making the Increment usable. If those activities depend on outside departments, the team cannot reliably deliver a Done Increment each Sprint and stakeholders receive value later than expected.
The strongest response is to reduce those essential handoffs by building or securing the needed capabilities within the Scrum Team. External specialists can still collaborate or advise, but the team should not rely on outside groups to complete core work required for Done. Tightening coordination or asking stakeholders for patience does not solve the underlying dependency.
The key takeaway is that cross-functionality supports end-to-end value delivery, not just faster completion of one type of work.
Cross-functionality means the Scrum Team has the essential skills to deliver a usable Done Increment without relying on external handoffs for core work.
Topic: Developing People and Teams: Self-Managing Teams
A Product Owner finishes a Sprint Review for a subscription product. The latest Done Increment increased trial sign-ups, but paid conversion did not improve. One stakeholder wants a shorter checkout, another wants more pricing detail, and the Developers ask the Product Owner to assign each idea to pairs next Sprint. The Product Goal is to improve self-service paid conversion. What is the next best step?
Best answer: B
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The Product Owner should inspect the new evidence against the Product Goal, make that information transparent, and adapt the Product Backlog accordingly. The Product Owner keeps accountability for Product Backlog order, while the Developers remain self-managing about how to turn selected work into a Done Increment.
This situation calls for empiricism and clear accountability. The Sprint Review produced stakeholder feedback and outcome evidence, so the Product Owner should use that information to inspect progress toward the Product Goal and adapt the Product Backlog. The Product Owner can collaborate with Developers to refine candidate items, but should not assign work or decide how Developers organize themselves during the Sprint.
A good next step is to:
After that, if items are selected in Sprint Planning, the Developers decide how to accomplish the work. The closest trap is treating stakeholder preference as direct Product Backlog control or turning the Product Owner into a task manager.
This keeps value evidence and Product Backlog order transparent while preserving the Developers’ self-management over how work is done.
Topic: Developing People and Teams: Self-Managing Teams
A Scrum Master coaching a Product Owner discovers two practices: the Product Owner keeps a private list of future ideas hidden from Developers until stakeholders “approve” them, and a sales director often reorders the visible Product Backlog before Sprint Planning. The Product Goal is to reduce checkout abandonment. At the latest Sprint Review, evidence showed mobile users abandon most often during address entry, while one large customer requested invoice export. What is the best Product Owner response?
Best answer: A
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The Product Owner is accountable for maximizing value and for effective Product Backlog management. The best response is to increase transparency by using one visible Product Backlog and to order it using evidence and the Product Goal, while still collaborating with stakeholders for input.
This scenario tests two linked Scrum points: Product Backlog transparency and Product Owner accountability. A hidden list reduces transparency and weakens the Developers’ shared understanding of possible future product work. Letting a stakeholder directly reorder the Product Backlog shifts accountability away from the Product Owner, which Scrum does not support.
The stronger response is to make product work visible in one Product Backlog, with items at different levels of detail as appropriate, and order that backlog using the Product Goal plus new evidence from the Sprint Review. Here, evidence suggests address-entry friction is a more important value and learning area than simply reacting to the loudest stakeholder request. Stakeholders should contribute input and constraints, but the Product Owner remains accountable for the ordering decision.
The key takeaway is collaboration without surrendering accountability.
This preserves Product Owner accountability while improving Product Backlog transparency and ordering for value, learning, and Product Goal progress.
Topic: Developing People and Teams: Self-Managing Teams
During a Sprint, a vice president tells two Developers to stop current work and build a special demo feature for a customer meeting tomorrow. The vice president also tells the Product Owner to “make it the top priority” and asks for a firm promise it will be ready. What is the best response from the Scrum Team?
Best answer: B
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The best response preserves Scrum accountabilities while still addressing the urgent request transparently. The Scrum Master helps the vice president understand Scrum, the Product Owner handles value and ordering, and the Developers decide how any change affects the Sprint plan and Sprint Goal.
When external authority creates pressure, the Scrum Team should collaborate in a way that protects self-management and makes trade-offs transparent. Stakeholders and leaders can raise urgent needs, but they do not directly assign work to Developers or take over Product Backlog ordering. In this case, the Scrum Master should coach the vice president on Scrum accountabilities and avoid false certainty. The Product Owner remains accountable for evaluating the request’s value and its place in the Product Backlog. The Developers remain accountable for the Sprint Backlog plan and for determining how any adaptation would affect progress toward the Sprint Goal.
A good response is to:
Avoiding the conversation is better than taking orders blindly, but it still fails to meet the stakeholder’s immediate need for clear, evidence-based feedback.
This keeps Product Backlog ordering with the Product Owner, Sprint planning with Developers, and Scrum coaching with the Scrum Master.
Use the PSPO I Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Use the full PM Mastery practice page above for the latest review links and practice route.