Free PSPO I practice test: 30 questions with answers

Inspection means checking artifacts and progress frequently so that problems surface early, which is exactly what the team is skipping. Predictability through a fixed upfront plan works against empiricism, commitment is a Scrum value rather than a pillar, and hierarchical control is not one of Scrum's pillars.

Scrum rests on empiricism, whose three pillars are transparency, inspection and adaptation. Hierarchy of approvals and fixed upfront scope both assume the outcome can be known in advance, which empiricism rejects.

The Product Owner is accountable for ordering the Product Backlog, so the Developers should have referred the request to the Product Owner. The other options invent rules that Scrum does not contain: Developers may talk to stakeholders, the Scrum Master does not approve backlog items, and backlog items are not limited to Sprint Planning.

A Sprint is a time-box of one month or less, and Sprints keep consistent durations throughout a development effort. Extending a Sprint, varying its length by vote, or ending it when the backlog is empty are not Scrum rules.

The Sprint Review is where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog, so feedback belongs there rather than in a later demo. Budget approval, approval of the Definition of Done and assigning individual items are not purposes of the Sprint Review.

The Sprint Retrospective inspects how the last Sprint went with regard to people, relationships, process and tools, and then plans improvements. Individual performance evaluation, stakeholder review of the Increment and backlog estimation belong to other activities or are not Scrum practices.

Each artifact has a commitment: the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog, and the Definition of Done for the Increment. Acceptance criteria are useful to teams but are not a commitment defined in the Scrum Guide.

When an item is not truly Done, the Increment is not usable and stakeholders receive a false picture of progress, because everyone must share one understanding of Done. The other options describe reassignments, Sprint length changes or Sprint Goal changes, none of which fixes the root problem.

Developers can renegotiate the scope of the Sprint Backlog with the Product Owner as more is learned, while protecting the Sprint Goal. A Sprint is cancelled only when its Sprint Goal becomes obsolete, extra hours are not a sustainable answer, and a Sprint is not stretched to fit the scope.

Only the Product Owner has the authority to cancel a Sprint, and this is considered when the Sprint Goal becomes obsolete. The Scrum Master, the Developers and senior management do not hold that authority under the Scrum Guide.

Scrum Teams are self-managing, so the Developers decide who does what, when and how rather than having the Product Owner assign tasks. The other options either name real Scrum accountabilities that this scenario does not touch or invent a rule that does not exist in the Scrum Guide.

Scrum Teams are self-managing: they decide internally who does what, when and how, without outside direction. The Scrum Master role is not optional, Product Owners do not assign tasks, and budgets and hiring are outside the Scrum Guide's definition.

Self-managing teams decide internally who does what, when and how, and the whole Scrum Team is accountable for the Increment. Personal velocity judgments, Product Owner technical dictation and Scrum Master assignment of components all conflict with that model.

Scrum Developers are cross-functional and have all the skills needed to create the Increment, so one cross-functional group removes the handoffs. An approval committee, shorter Sprints or extra Product Owners add coordination overhead and do not give the team the skills it lacks.

Openness is the Scrum value about sharing the work and its challenges, which is the behaviour the Scrum Master wants to encourage. Commitment, focus and respect are also Scrum values, but none of them describes speaking openly about problems, and the respect option wrongly limits respect to senior managers.

The Scrum Master coaches the Developers toward self-management rather than directing them, so facilitating a discussion where they own the decision is right. Making the decision yourself, handing it to the Product Owner or removing a member are not the Scrum Master's role and do not build self-management.

The Scrum Master coaches the Developers in self-management and cross-functionality, as the Scrum Guide describes. Assigning work, approving every change and reporting individual progress to management each undermine the Developers' self-management.

The Scrum Guide states that Scrum recognises no sub-teams or hierarchies within the Developers, so the Scrum Team works toward one Sprint Goal. The other options describe structures that Scrum does not prescribe or endorse.

The Scrum Guide asks for a Scrum Team small enough to stay nimble but with every skill needed to create the Increment, so the team's skill needs and agility are the criteria. Sub-teams, budget approval and HR headcount limits are not what the Scrum Guide uses to decide team composition.

The Scrum Master facilitates, so that the Developers, who decide how the work is done, reach their own agreement. Deciding for them, handing the choice to the Product Owner or splitting the team does not build the team's self-management.

Scrum supports forecasts drawn from empirical data, and those forecasts are updated as the team learns. Committing to a guaranteed date through longer hours, refusing any forecast, or handing the date to the Scrum Master do not reflect the Scrum approach.

The Sprint Backlog is the Developers' forecast of the functionality for the Sprint, plus a plan for delivering it. The Product Backlog is an ordered list of known work, the Increment is the sum of completed items, and the Definition of Done is a quality commitment rather than a forecast.

A product vision and product goal give the Product Owner a long-term direction against which each request can be judged for its contribution to value. Ordering by loudness, arrival time or effort ignores value and the product's direction.

Product value is measured by outcomes for customers and the business, not by output or activity. Completed items, story points and the number of meetings measure output or activity, which can rise while real value stays flat.

Refinement makes the items at the top of the Product Backlog more detailed and small enough for the Developers to select in a Sprint, which keeps the backlog useful. Uniform detail, Scrum Master authorship of items and delaying refinement until the Review all work against that goal.

The Product Owner orders the Product Backlog to maximise value and ensures it is visible, transparent and clear. The Developers do not hold sole rights to add items, the Scrum Master does not order items, and items at the bottom do not need full estimates before Sprint Planning.

Business strategy shapes the Product Goal, and the Product Owner keeps the Product Backlog aligned with it. Ignoring the change, rewriting the Definition of Done for one customer type, or creating teams without consultation do not respond to the strategy.

The Sprint Review is where stakeholder feedback is gathered, and the Product Owner adapts the Product Backlog by value. Dismissing the customer, delaying the feedback or hiding it from the team ignores the empirical feedback loop that Scrum relies on.

The Sprint Review is the event where the Scrum Team and stakeholders inspect the Increment and provide feedback that adapts the Product Backlog. The Daily Scrum, Sprint Planning and Sprint Retrospective are primarily internal to the Scrum Team.

Observed throughput from recent Sprints, applied to the work still left in the Product Backlog, gives a forecast grounded in what the team has actually delivered. Individual hour estimates, feelings of confidence and multiplying Sprint length by headcount do not reflect actual delivery.