An original foundation guide connecting observable evidence to a defensible next decision; not an official exam or calibrated readiness assessment.
Start with the decision, not an estimation ritual
In a PSM I preparation case, a team might be asked to select work, explain a delivery forecast or respond to a stakeholder request. These are related conversations, but they are not interchangeable. Identify who is making the decision, which goal matters and what evidence is available. Scrum establishes accountabilities and opportunities for inspection and adaptation. It does not prescribe one universal estimation scale, backlog scoring formula or prediction technique. A local practice can help a team without becoming a mandatory rule of the framework. In an explanation, separate the actual Scrum rule from your proposed practical way to apply it.
Refinement makes work clearer without freezing the future
The Product Backlog is emergent and ordered. Refinement breaks down and further defines its items, adding useful detail such as description, order and size. An item that can be Done within a Sprint can become ready for selection. This is not a promise that the item will be selected in the next Sprint or a declaration that all uncertainty has disappeared. It also does not establish a mandatory external approval gate. A team may choose a shared checklist if it helps understanding, but a checklist should not replace the conversation or be described as an additional formal Scrum event. Ask what new understanding the activity creates for the next decision.
Preserve accountability while sharing useful work
The Developers doing the work are responsible for sizing. The Product Owner can help clarify needs and trade-offs and remains accountable for effective Product Backlog management, including ordering. Other people can contribute research, suggestions and specialist knowledge. That collaboration does not turn Product Owner accountability into a committee vote. Conversely, being accountable for ordering does not mean privately dictating how Developers perform the work. A refinement conversation can expose a dependency that changes the value or risk of an item. Keep that evidence visible so the appropriate people can make their decisions rather than using role labels to prevent discussion.
Forecast with the changed conditions in view
A fictional team completed five to seven similarly sized items in each recent Sprint. Next Sprint, two Developers will be unavailable and one remaining item depends on a supplier experiment. A stakeholder asks for a guaranteed date for twelve remaining items. The historical range is relevant evidence, but it is not a guarantee. Developers can consider past performance, upcoming capacity and the Definition of Done when forecasting the Sprint. The new availability and unresolved dependency are material assumptions to discuss. The case does not contain enough information to compute a defensible exact date by dividing twelve by the previous average. Describe the uncertainty instead of hiding it behind arithmetic.
Distinguish the Product Goal from an accumulation of requests
A Product Goal gives direction toward a future state of the product. The team must fulfill or abandon one Product Goal before taking on the next. That focus does not mean the Product Backlog stays unchanged. Learning, stakeholder evidence and environmental changes can affect the work needed to improve the product. During a Sprint, the Sprint Goal provides a more immediate objective; the plan can be adapted as more is learned. When a request arrives, ask which goal or decision it affects. Automatically accepting every urgent request hides trade-offs. Automatically rejecting all new information prevents empirical adaptation. Explain the relevant goal and the conversation needed to inspect the impact.
Treat stakeholder disagreement as input to inspect
Suppose two stakeholders request incompatible improvements. Their requests can provide valuable evidence about different customer needs, risks or constraints. A useful facilitated discussion makes those concerns understandable and keeps Product Owner accountability clear. A majority vote does not automatically replace ordering accountability, and a high-ranking stakeholder does not automatically assign Developers tasks. Equally, accountability should not be used to make stakeholder evidence invisible. Ask what the participants have learned, how it changes the Product Backlog discussion and what remains uncertain. The practical questions in this paragraph are original teaching suggestions, not a prescribed facilitation script required by the Scrum Guide.
Use a short explanation that reveals its limits
For each practice case, write four connected statements: the decision being made, the relevant accountability or commitment, the evidence that changes the decision, and the uncertainty that remains. For a large unclear item, that might mean further decomposition, Developer sizing and Product Owner trade-off discussion, without inventing a readiness board. For a changed-capacity forecast, it might mean inspecting the old evidence and updating assumptions, without promising a date unsupported by the case. Use the linked course, cards and original questions to practise these distinctions. Repeated success on a fixed bank is familiarity with that bank; it does not establish an official examination score, calibrated difficulty or demonstrated workplace effectiveness.
Apply the guide
A team schedules a weekly refinement appointment. Does that make refinement a mandatory additional Scrum event?Reveal explanation
No. Refinement is an ongoing activity. The appointment is a local implementation choice, not an additional mandatory event with a framework-prescribed timebox.
A historical average suggests two Sprints, but upcoming capacity and dependencies have changed. What should a forecast explanation include?Reveal explanation
The relevant observed performance, upcoming capacity, work readiness and dependency assumptions, plus uncertainty. The old average alone does not justify a guaranteed date.
Turn the idea into practice.
Apply the rule to a new case, then explain your choice.
Practice this skillSources & authorship
Official references support the concepts. Original fictional examples and diagrams are authored for this guide; qualified educator review remains pending.
Original OpenExam teaching and fictional cases; no official examination questions reproduced.
Independent educator review is pending. This guide is not an official exam paper or a video transcript.
The Scrum Guide — November 2020