Try 10 focused CSM questions on Scrum Team & Accountabilities, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | CSM |
| Topic area | Scrum Team & Accountabilities |
| Blueprint weight | 18% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Scrum Team & Accountabilities for CSM. 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: 18% 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: Scrum Team & Accountabilities
A Product Owner (Jordan) returns after being out for a week. Sprint Planning is tomorrow, and Jordan sees this Product Backlog excerpt.
Order | PBI | Item | “Ordered by” note
1 | 41 | Guest checkout | Priya (Business Analyst)
2 | 18 | Refactor payment svc | Developers
3 | 55 | Add loyalty points | Sales VP
What is the best next action for Jordan, consistent with Scrum?
Best answer: D
What this tests: Scrum Team & Accountabilities
Explanation: In Scrum, the Product Owner is accountable for maximizing value and for ordering the Product Backlog. Others can help by providing analysis, recommendations, or even doing the mechanics of reordering, but the Product Owner remains accountable for the final ordering. The next step is to inspect the current order, align it to value and the Product Goal, and make the ordering transparent.
The core concept is delegation of work versus accountability. The Product Owner can delegate tasks like gathering stakeholder input, drafting a proposed order, or facilitating refinement, but cannot delegate accountability for Product Backlog ordering and value.
In this exhibit, multiple parties have influenced the ordering (“ordered by” notes), which is fine as input, but it creates ambiguity about who owns the final order going into Sprint Planning. Jordan should inspect the proposed order, reconcile conflicts (e.g., stakeholder desires vs. technical risk), and then clearly publish and communicate the Product Backlog order as the Product Owner’s decision.
Letting others’ changes stand without PO review blurs accountability and reduces transparency.
The Product Owner may delegate ordering work, but must own and communicate the final ordering decision.
Topic: Scrum Team & Accountabilities
A Scrum Team is midway through a Sprint. The Scrum Master notices the Sprint Backlog is organized like this:
Sprint Goal: Enable guest checkout
Sprint Backlog (excerpt):
- Backend Team: Create checkout API (In Progress)
- Frontend Team: Build guest UI form (To Do)
- QA Team: Write test plan (To Do)
- Lead Dev: Approve merges (Blocked)
What is the best next action to align with Scrum’s rule of no sub-teams or titles and strengthen accountability?
Best answer: C
What this tests: Scrum Team & Accountabilities
Explanation: The exhibit shows work split into specialty sub-teams and a titled gatekeeper, which weakens shared ownership. In Scrum, the Developers are a cohesive unit with no sub-teams or titles, and they collectively own the Sprint Backlog and accountability for a Done Increment. The best move is to help them reorganize around the Sprint Goal and swarm as needed.
Scrum intentionally has no sub-teams or titles within the Scrum Team because creating internal hierarchies and handoffs dilutes clear accountability. The Developers are a single, self-managing group accountable for creating a usable Increment each Sprint that meets the Definition of Done.
In the exhibit, labels like “Backend Team/Frontend Team/QA Team” and “Lead Dev: Approve merges” encourage siloed ownership and a dependency bottleneck. A Scrum-aligned next step is to coach the Developers to manage the Sprint Backlog as one team:
This preserves one-team accountability for outcomes instead of component-level accountability for tasks.
Removing sub-team/titled ownership reinforces that Developers are jointly accountable for a Done Increment that meets the Sprint Goal.
Topic: Scrum Team & Accountabilities
Midway through a Sprint, the Product Owner starts assigning tasks to individual Developers and is the only person updating the Sprint Backlog in the tool. Developers stop updating their plan and progress there, and focus only on completing the assigned tasks.
What is the most likely near-term impact?
Best answer: A
What this tests: Scrum Team & Accountabilities
Explanation: Developers are accountable for creating and adapting the Sprint Backlog as their plan for achieving the Sprint Goal. If the Product Owner controls updates and Developers stop maintaining it, the Sprint Backlog quickly becomes an unreliable picture of remaining work. That immediately reduces transparency and weakens inspection and adaptation toward the Sprint Goal.
The Sprint Backlog is the Developers’ plan for the Sprint: it is created by Developers in Sprint Planning and then updated by Developers throughout the Sprint as they learn and as work emerges. If Developers stop owning updates (and instead follow assignments while the Product Owner alone updates the artifact), the Sprint Backlog stops reflecting the team’s current understanding of what’s needed to meet the Sprint Goal.
Near-term, this harms empiricism:
This is more immediate than downstream effects like forecasting quality or stakeholder confidence.
When Developers don’t own and update the Sprint Backlog, it quickly stops being a transparent, real-time plan to support progress toward the Sprint Goal.
Topic: Scrum Team & Accountabilities
Which statement best describes how the Product Owner collaborates with stakeholders while maintaining a single ordered Product Backlog?
Best answer: D
What this tests: Scrum Team & Accountabilities
Explanation: Scrum uses a single Product Backlog to make upcoming work transparent and comparable. Stakeholders can provide input and requests, but the Product Owner is accountable for the content and ordering of that one Product Backlog. Collaboration happens through conversation and feedback, not by splitting ownership of the backlog.
The core Scrum concept is that there is one Product Backlog for a product, and it is an ordered, emergent list used to maximize value. Stakeholders collaborate by sharing needs, feedback, and ideas, which can become Product Backlog items. However, the Product Owner remains accountable for the Product Backlog’s content, ordering, and transparency, so stakeholder input does not create multiple competing backlogs or require stakeholder sign-off to order items.
Key takeaway: stakeholder collaboration influences the backlog, but it does not change the Product Owner’s single-backlog accountability.
The Product Owner is accountable for one transparent, ordered Product Backlog while collaborating with stakeholders for input.
Topic: Scrum Team & Accountabilities
Mid-Sprint, the Product Owner tells the Scrum Master, “I’ve delegated Product Backlog ordering to a senior Developer because I’m in back-to-back meetings.” Stakeholders are now asking the Developers to move items around for an upcoming release.
What is the FIRST thing the Scrum Master should clarify before suggesting next steps?
Best answer: D
What this tests: Scrum Team & Accountabilities
Explanation: In Scrum, the Product Owner is accountable for effective Product Backlog management, including ordering to maximize value. The Product Owner can delegate tasks, but not shift accountability. Before acting on stakeholder pressure or team actions, clarify how ordering will be handled and how the Product Owner will stay accountable and available for decisions.
The core issue is delegation versus accountability. The Product Owner remains accountable for maximizing value and for effective Product Backlog management (including ordering), even if they delegate specific backlog management activities to others. When Developers and stakeholders start changing priorities directly, transparency about who makes ordering decisions and how those decisions connect to the Product Goal is missing.
A useful first clarification is:
Only after that is clear should the Scrum Master coach on appropriate collaboration and boundaries between stakeholders, Developers, and the Product Owner.
The Product Owner may delegate backlog management work, but must retain accountability for value and ordering, so decision-making and accountability need to be transparent first.
Topic: Scrum Team & Accountabilities
A Scrum Team starts a 2-week Sprint. The Developers can code and design, but they do not have testing skills. The organization decides that all testing must be done by a separate QA group that is only available during the last 2 days of the Sprint.
What is the most likely near-term impact of this decision?
Best answer: A
What this tests: Scrum Team & Accountabilities
Explanation: A cross-functional Scrum Team has the skills needed to deliver a Done Increment without relying on outside handoffs. Moving testing to an external group late in the Sprint introduces waiting, delayed feedback, and a bottleneck. In the near term, this most directly threatens timely Sprint Goal progress and completion of work to the Definition of Done.
In Scrum, the Developers are expected to be cross-functional as a team: collectively they have all the skills necessary to create a usable Increment each Sprint. When a key skill (like testing) sits outside the Scrum Team, work must be handed off and waits in queues, which reduces flow and delays inspection of quality. With testing only available in the last 2 days, the team gets late feedback and may discover unfinished or failing work too late to adapt, making Sprint Goal progress less predictable. Cross-functionality reduces these handoffs and delays by enabling the team to complete items to the Definition of Done within the Sprint.
The key takeaway is that external dependencies for core skills create near-term bottlenecks and delay completion.
Because the team is not cross-functional, the handoff to QA creates a bottleneck that slows progress toward a Done Increment.
Topic: Scrum Team & Accountabilities
Midway through a Sprint, several defects are discovered in new functionality. The Developers decide to fix the defects that threaten the Sprint Goal and adjust their plan to keep the Sprint Goal achievable.
Which option is the best evidence/indicator that the Developers handled the defects appropriately while protecting the Sprint Goal?
Best answer: C
What this tests: Scrum Team & Accountabilities
Explanation: In Scrum, the strongest evidence of progress, quality, and value is a usable Increment that meets the Definition of Done. When defects are discovered during the Sprint, protecting the Sprint Goal is validated by still producing a Done Increment that achieves that goal, not by intermediate activity outputs. This keeps inspection focused on real results rather than process artifacts.
Defects found during a Sprint are part of the work needed to produce a usable Increment. Developers adapt their plan as they learn, typically by updating the Sprint Backlog and making trade-offs that preserve the Sprint Goal while ensuring work meets the Definition of Done.
The most reliable indicator that defects were handled appropriately is outcome-based: a Done Increment that meets the Definition of Done (quality) and achieves the Sprint Goal (value). Logs, charts, and test reports can support transparency, but they do not prove the Increment is usable or that the Sprint Goal was met.
The key takeaway is to validate by inspecting the Done Increment against the Definition of Done and Sprint Goal, not by tracking activities.
The most direct validation is an Increment that is actually Done (quality met) and still delivers the Sprint Goal (value).
Topic: Scrum Team & Accountabilities
Midway through a Sprint, stakeholders ask how the Scrum Team is preventing technical debt while still delivering new features. The Developers have started several code cleanups and drafted an “architecture improvement plan,” but nothing has been integrated yet.
Which option is the best evidence that progress is being made while maintaining sustainable quality in Scrum?
Best answer: C
What this tests: Scrum Team & Accountabilities
Explanation: In Scrum, the most reliable evidence of progress and quality is a Done Increment that meets the Definition of Done. It demonstrates integrated, tested, potentially releasable work, which is how the team validates sustainable delivery and avoids hidden work and deferred quality. Plans and activity counts do not validate outcomes.
Reducing technical debt and supporting sustainable delivery requires making quality visible in the product, not just in intentions or effort. In Scrum, the key quality commitment is the Definition of Done, and the primary evidence that quality is being maintained is a Done Increment: integrated work that meets the Definition of Done and is usable.
A plan, time spent refactoring, or a larger list of debt items can be helpful signals, but they are not outcome validation. Only a Done Increment provides transparency that improvements and features are actually integrated, verified, and not creating hidden or deferred work that becomes technical debt. The strongest indicator is therefore working product that satisfies the Definition of Done.
A Done Increment is usable and integrated, providing transparent evidence that quality work is complete and technical debt is being managed through the Definition of Done.
Topic: Scrum Team & Accountabilities
A Scrum Team has started referring to itself as the “UI Team” and the “API Team.” One Developer is called the “Tech Lead” and assigns work to each group. This Sprint, integration happened late, and the Increment is not “Done.” The Product Owner asks, “Which team owns this failure?”
As Scrum Master, what is the best next step?
Best answer: D
What this tests: Scrum Team & Accountabilities
Explanation: In Scrum there are no sub-teams or titles within the Scrum Team because they weaken the single, shared accountability for delivering a valuable, “Done” Increment each Sprint. The next step is to use an empirical event to inspect how the split and title are affecting outcomes and adapt the team’s way of working back toward one cohesive unit.
Scrum avoids sub-teams and internal titles because they create handoffs, local ownership, and “us vs. them” thinking, which undermines the Scrum Team’s shared accountability for the Increment and the Sprint Goal. Here, the split into “UI” and “API” groups and a “Tech Lead” assigning work contributed to late integration and an unfinished Increment.
A good next step is to use the Sprint Retrospective to inspect and adapt:
Clarifying a single team accountability enables faster collaboration and clearer responsibility without creating hierarchy.
Scrum has one Developers accountability, so the team should inspect how sub-team labels/titles harmed collaboration and adapt to restore shared ownership of the Increment.
Topic: Scrum Team & Accountabilities
Near the end of a Sprint, the Developers say they are “done,” but the Product Owner is unsure whether the Increment is actually useful and worth showing at the Sprint Review. Stakeholders have not been engaged during the Sprint.
As the Scrum Master, what is the most important thing to clarify first before deciding what to do next?
Best answer: B
What this tests: Scrum Team & Accountabilities
Explanation: A valuable, useful Increment is evaluated against the purpose it was built to achieve. Clarifying the Sprint Goal and the expected outcome creates transparency about what “valuable and useful” means for this Sprint, enabling inspection and adaptation at the Sprint Review.
In Scrum, the Scrum Team is responsible each Sprint for creating an Increment that is valuable and useful, and the Sprint Goal provides the primary context for assessing that. If the Product Owner is unsure whether the Increment is worth showing, the first clarification is what outcome the Sprint was meant to achieve (Sprint Goal) and what “value” looks like for that goal. With that shared understanding, the team can then inspect whether what was built supports the goal and decide what to adapt (e.g., scope, collaboration, or how to make the Increment demonstrably usable). Without clarity on the Sprint Goal and intended outcome, discussions about completion or progress metrics risk optimizing for activity rather than value.
You first need a shared understanding of the Sprint Goal and intended outcome to judge whether the Increment is valuable and useful.
Use the CSM Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the CSM guide on PMExams.com, then return to PM Mastery for timed practice.