Free CSM practice test: 30 questions with answers

The Scrum Team as a whole is accountable for the Increment, and there are no sub-teams or individual owners of delivery. The Product Owner is accountable for value and ordering, the Scrum Master for the Scrum framework, and the Developers for building the work, so none of them alone is accountable.

Within a Scrum Team there are no sub-teams or sub-hierarchies, and the team is self-managing. Approving the split or giving each sub-team its own Sprint Goal breaks that structure, and making the split conditional on velocity misreads the framework.

The Product Owner is accountable for ordering the Product Backlog, and the organization must respect those decisions. The Developers can share dependency information, but the request should go through the Product Owner rather than override the order or move to the Scrum Master or Developers.

The Product Owner is accountable for maximizing product value and for managing the Product Backlog, including ordering its items. Staffing decisions, facilitating the Daily Scrum, and choosing the technical architecture are not listed as Product Owner duties; the Developers decide how the work is built and conduct the Daily Scrum.

The Sprint Retrospective is where the Scrum Team inspects how the last Sprint went, including people, process, tools and relationships, and plans improvements. The Sprint Review inspects the Increment with stakeholders, Sprint Planning sets up the next Sprint, and the Daily Scrum inspects progress toward the Sprint Goal.

The Sprint Review inspects the Increment with stakeholders and adapts the Product Backlog based on their feedback. Agreeing on the Sprint Goal belongs to Sprint Planning, individual performance is not a Sprint Review topic, and technical design is decided by the Developers.

The Daily Scrum is a Developers' event that inspects progress toward the Sprint Goal and adapts the Sprint Backlog, not a status report to managers. Routing reports to a manager, extending the meeting to stakeholders, or assigning tasks from outside the team all turn it into a status meeting.

The Scrum Guide lets the Developers choose the structure and techniques of the Daily Scrum, provided the meeting focuses on progress toward the Sprint Goal. The Product Owner, the Scrum Master and a project manager do not own the format of the event.

When a Sprint is cancelled, completed Done items are reviewed, and incomplete Product Backlog items are re-estimated and put back on the Product Backlog. Discarding all work, moving unfinished items automatically into the next Sprint, or giving the Scrum Master release authority are not part of the Scrum Guide.

A story that is not tested or integrated does not meet the Definition of Done, so it cannot be counted in the Increment. The Scrum Master helps the team apply that shared standard, rather than letting the Product Owner or the Sprint Review override it.

Facilitation means guiding the group's process so every member can contribute, and a round-robin is a simple technique for that. Telling the group the answer, handing leadership to the dominant voices, or delaying the meeting does not give the quieter Developer a fair voice in the discussion.

Facilitation helps a group run its own process and reach its own outcomes, while the facilitator stays neutral on content. Directing technical choices, teaching structured lessons, and managing pay and performance reviews are different activities that do not define facilitation.

Facilitation keeps a group's process moving and gives every voice a chance, while the group decides the content. Teaching, mentoring, and one-to-one coaching would each have the Scrum Master supplying or drawing out content, which is not the main role in this workshop.

Fist of five gives a fast, visible read on each person's level of support, which suits a short time window. A dictated choice, a multi-week workshop, and a single delegate do not show where each Developer stands within the few minutes available.

Consensus means the group works until every member can support or at least accept the outcome, which is different from a vote. Majority and plurality votes can leave dissenting members, and an autocratic decision skips group input altogether.

Dot voting and silent brainstorming both collect each person's input before the group discusses or decides, which spreads influence across the group. Delegation to a senior person, letting the last speaker decide, and a coin flip all let a few people or chance settle the outcome.

Coaching uses open questions to help an individual find their own answers and next steps, which matches the questions in this scenario. Mentoring shares personal experience, teaching transfers specific skills, and facilitation guides a group process, so each is a weaker fit here.

Mentoring is an ongoing relationship in which a more experienced person shares advice and perspective to support someone's growth. Facilitation guides a group process, coaching uses questions to surface individual answers, and teaching demonstrates a specific skill in a focused session.

Teaching transfers a specific skill through direct instruction and demonstration, which matches the step-by-step walkthrough here. Coaching would have the Developer work out the steps, mentoring would focus on career experience, and facilitation would guide a group decision.

A parking lot keeps the idea visible and respected while protecting the agenda, and agreeing when it will be discussed gives the group a clear next step. Shutting the idea down, letting the debate run on, or forcing a decision without the group damages the workshop's purpose.

The Scrum Master is a true leader who serves the team and the organization, which means helping others make their own decisions and understand Scrum rather than taking over product or task decisions. Making product decisions, assigning every task, or withdrawing from conflict would each fail to serve the team.

The Scrum Guide describes the Scrum Master as a true leader who serves the Scrum Team and the larger organization, including coaching the team and removing impediments. Project management, technical approval, and staffing allocation are not Scrum Master duties.

Shortcuts that skip tests and refactoring create technical debt, which makes each later change slower and riskier. Backlog volume, Sprint length, and a supposed quality buffer do not explain the rising delivery time and bug count.

Technical debt is the accumulated future cost of shortcuts that trade quality for short-term speed, such as skipped tests or messy code. The other options describe unestimated backlog items, financial debt to suppliers, or a deliberate scope deferral, none of which is what the term means.

Automated tests and continuous integration catch defects as code changes, which keeps the Increment releasable at the end of every Sprint. Longer Sprints, extra headcount, and late integration delay feedback and hide defects rather than supporting a releasable Increment.

Peer review or pairing and a current Definition of Done both build quality into each change and apply consistent criteria. Skipping refactoring, testing only some features, and judging quality by story points all weaken the Increment's quality.

Coaching the Product Owner on backlog refinement and value ordering builds their own capability, which is how a Scrum Master supports the role. Writing items for them, ignoring vague requests, or routing work around the Product Owner would take over or undermine the role.

A shared, transparent view of progress reduces interruptions while leaving backlog ordering and priority decisions with the Product Owner. Making priority decisions for them, sending managers to the Developers, or pausing customer contact would each undermine the Product Owner's role or the product's value.

Organizational impediments are beyond the team's control, so the Scrum Master escalates them to the people who can change the process and helps the organization address them. Skipping testing, working around controls on a personal server, or waiting for the Sprint Review would hide or ignore the impediment.

A Scrum Master leads by serving, influencing through evidence and facilitation rather than authority, so they show the executive what the team's data supports and involve the Product Owner on scope. Accepting an unsupported date, pushing the Developers to overwork, or refusing to engage all fail the team and the organization.