I85PREP
⌘ K
PECB Certified PSM Basic study materials
PECB Certified PSM Basic study resources

PECB Certified PSM Basic: Applying Scrum in Practice

PECB Certified PSM Basic · Work through your exam, one topic at a time.

All guide sections

Applying Scrum in Practice

This domain, Applying Scrum in Practice, tests whether you can use the framework in realistic situations: planning under uncertainty, managing the Product Backlog, protecting the Sprint Goal, improving quality, and collaborating with stakeholders. It rewards empirical decisions over rigid plans.

Core rules and concepts

  • The Product Backlog is emergent. Refinement is ongoing; the Product Owner orders items by value, risk, and dependency, and the team slices work small enough to finish within a Sprint.
  • The Sprint Goal is a single objective for the Sprint. Scope may be clarified and renegotiated with the Product Owner as more is learned, but the goal should remain stable; only the Product Owner can cancel a Sprint, and only when the goal becomes obsolete.
  • Forecasting uses past data and current evidence, not guarantees. Velocity is a planning aid, not a target or performance rating.
  • The Definition of Done creates transparency. If an Increment does not meet it, it is not complete and should not be released as done.
  • The Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt the plan; it is not a status report to management.

Worked example

Mid-Sprint, a sales leader demands an urgent feature. The Product Owner assesses value and risk with the Developers, checks the Sprint Goal, and explains the trade-off to the stakeholder. If the request can wait, it is ordered in the Product Backlog. If it cannot, the team negotiates scope with the Product Owner while protecting the Sprint Goal; canceling the Sprint is reserved for when the goal is obsolete. Reasoning: empiricism means adapting with transparency, not silently adding scope or automatically saying yes.

Traps that cost marks

  • Treating velocity as a commitment or comparing teams by it.
  • Accepting mid-Sprint scope without a trade-off or Product Owner decision.
  • Changing the Sprint Goal casually or canceling Sprints to handle every request.
  • Calling work done when it misses the Definition of Done.
  • Turning the retrospective into a complaint session with no owned experiments.