Free PSM I practice test: 30 questions with answers

Scrum relies on the three pillars of empiricism: transparency, inspection, and adaptation. The Scrum Values (commitment, focus, openness, respect, and courage) are a separate set, and predictability and control describe the defined process model that Scrum replaces.

Focus means concentrating effort on the committed Sprint Backlog so the Sprint Goal stays achievable. Openness and respect are real Scrum Values, but the Developer is not mainly sharing information or honoring the request, and refusing all incoming work overstates what happened.

The Scrum Team is made up of a Product Owner, a Scrum Master, and the Developers, with no sub-teams or hierarchy. The other options add leads, committees, or rankings that Scrum does not define.

Scrum places accountability for ordering the Product Backlog on a single Product Owner, who is one person rather than a committee. Splitting the backlog or voting each week keeps the conflict alive, and the Scrum Master does not decide the backlog order.

Sprint Planning produces a Sprint Goal that explains the value the Sprint should deliver, along with the Sprint Backlog. A fixed release date, hour-level plans, and signed agreements are not required outputs of Sprint Planning in Scrum.

The Sprint Review is where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog based on feedback. Individual performance reviews are not part of Scrum, Sprint Planning plans the next Sprint, and process improvement belongs to the Sprint Retrospective.

An item that does not meet the Definition of Done is not part of the Increment and cannot be presented as Done, so it returns to the Product Backlog for future consideration. Presenting it as Done, even with a note, hides incomplete work from the team and stakeholders.

The Product Goal is the commitment of the Product Backlog and describes a future state of the product. The Sprint Goal belongs to the Sprint Backlog, the Definition of Done belongs to the Increment, and a release date is not a Scrum commitment.

Only the Product Owner can cancel a Sprint, which is usually done when the Sprint Goal becomes obsolete. The Scrum Master, the Developers, and stakeholders can offer input, but none of them holds the cancellation authority.

The Sprint Retrospective is where the team inspects how the last Sprint went and chooses improvements for the next Sprint. Stakeholder acceptance happens at the Sprint Review, the Scrum Team crafts the Sprint Goal together during Sprint Planning, and the retrospective does not replace the Daily Scrum.

A self-managing Scrum Team decides internally who does what, when, and how the work gets done. Scrum gives no manager, Scrum Master, or Product Owner the job of assigning tasks, and pay or hiring decisions are not part of that definition.

Facilitation means using techniques that give every member a voice before open discussion starts. Letting a senior person decide, deferring the issues, or handing the event to the Product Owner would weaken the team's own inspection.

A coaching Scrum Master builds the team's capability by asking questions that help the Developers reason through options and decide. Making the choice, passing it to the Product Owner, or imposing a standard takes ownership away from the Developers, who are accountable for how the work is done.

The Scrum Master removes impediments and coaches the Scrum Team toward self-management and cross-functionality. Ordering the backlog is the Product Owner's accountability, and the Developers decide their own work, so assigning people to areas or approving releases is not part of the Scrum Master role.

Scrum does not recognize titles or sub-teams within a Scrum Team, because all Developers share the same accountabilities. Approving titles, tracking sub-teams, or appointing leads would create a hierarchy that Scrum avoids.

Developers create the plan for the Sprint, uphold quality through the Definition of Done, adapt their plan each day, and hold each other accountable as professionals. The other options describe command-and-control task assignment or sub-team structures that Scrum does not use.

Removing impediments is a Scrum Master accountability, and making a blocker visible lets the organization act on it. Waiting, changing the Sprint Goal to route around the problem, or deferring it to the Sprint Review would leave the impediment in place for weeks.

Coaching the organization includes helping managers understand that a Scrum Team decides how to do its own work. Assigning tasks yourself, passing the problem to the Product Owner, or adding an approval process would keep the same command structure in place.

The Scrum Master keeps events focused on their purpose and within their time-box, which for Sprint Planning means the Sprint Goal and the Sprint Backlog. Detailed design for work that has not started can wait, while letting the event run on or restarting it would not help the team plan.

A coaching Scrum Master helps the Product Owner build skill in describing and ordering Product Backlog items, since the Product Owner stays accountable for the backlog. Writing the items for them, handing the work to Developers, or removing the accountability would weaken the Product Owner's role.

Current Value is the value the product delivers now. Unrealized Value covers value customers want but do not yet receive, while Time to Market and Ability to Innovate measure speed and experimentation.

The Product Owner is accountable for ordering the Product Backlog to maximize value, so the right move is to explain the trade-off transparently rather than follow a personal preference. Handing the decision to the Developers, moving the item by rank, or slipping it into the current Sprint would bypass that accountability.

The Product Owner orders the Product Backlog to maximize value and keeps it transparent and understood. Changes to the Sprint Backlog belong to the Developers, and Scrum does not require hour-based estimates or set anyone's working hours.

Scrum forecasts use observed throughput to show a range of likely outcomes, and the range is revised as new data arrives. A fixed commitment, a simple division of features by team size, or refusing to forecast at all ignores that evidence.

A burn-up chart plots completed work against the total scope, so a growing scope line is visible next to progress. A burn-down chart shows only remaining work, while a task board and a velocity chart do not show total scope for the release.

The Sprint Review exists to gather feedback, which the Product Owner records as Product Backlog items and orders by value. Dismissing the feedback, rebuilding without ordering it, or waiting until release delays learning from the Increment.

The Product Goal is the long-term target for the product, and each Sprint Goal moves the team a step toward it. The Sprint Goal does not replace the Product Goal, and the Product Goal is a target rather than a task list.

Unrealized Value is the value customers want but the product does not yet deliver, so repeated unmet needs point there. High current satisfaction describes Current Value, while Time to Market and Ability to Innovate concern delivery speed and experimentation rather than unmet needs.

The Product Backlog is an emergent, ordered list of what is known to be needed to improve the product, and its contents change as the team learns. The current Sprint's tasks belong to the Sprint Backlog, while a fixed list or approval schedule does not describe the Product Backlog.

Time to Market measures how fast ideas move from conception to customers. Current Value, Unrealized Value, and Ability to Innovate measure the value delivered now, unmet needs, and experimentation capacity.