Reviewed 10 October 2026 against the linked published scope. Framework, people/teams and agile product management; the current Scrum Guide is the November 2020 edition.
Memory hook: Three accountabilities, three artifacts and commitments, five events; inspect real value.
Read the essentials, cover the answers and explain the decision aloud. Open the topic summaries below whenever a distinction is unclear.
Empiricism, values and accountabilities
- Scrum supports complex work through transparency, inspection and adaptation. Making unfinished work appear done damages the evidence needed for good decisions. Lean thinking reduces waste and focuses on essentials.
- Commitment, focus, openness, respect and courage support effective inspection and honest adaptation. Scrum gives a lightweight framework, not a complete project procedure or a promise to remove uncertainty.
- A Scrum Team includes one Product Owner, one Scrum Master and Developers. It is cross-functional and self-managing, usually ten or fewer people. There are no separate internal subteams or hierarchies in the framework's team model.
- The Product Owner is accountable for product value and effective Product Backlog management, including ordering and clarity. Work can be delegated; accountability remains. A committee does not replace the single Product Owner accountability.
- Developers plan/build the usable Increment, adapt the Sprint plan and uphold quality. They decide how to do the work; a manager or Scrum Master does not assign each person's Daily Scrum tasks.
- The Scrum Master establishes Scrum and supports team effectiveness through teaching, coaching, facilitation and organizational change. Removing impediments does not mean becoming the team's permanent secretary or technical boss.
Events and timeboxes
- A Sprint lasts one month or less and contains the other events. A new Sprint follows immediately. Protect its goal, maintain quality and refine understanding; scope can be clarified with the Product Owner as learning occurs.
- Sprint Planning establishes purpose, selected work and an initial delivery plan. For a one-month Sprint it is at most eight hours. Developers forecast work using capacity, past performance and the Definition of Done.
- The Daily Scrum is 15 minutes for Developers to inspect progress toward the Sprint Goal and adapt their plan. It is not a required status report to a manager, and there is no mandatory three-question script.
- Sprint Review inspects the outcome with stakeholders and adapts future direction; it is a working discussion, not just a presentation or release gate. Its one-month-Sprint maximum is four hours.
- Sprint Retrospective improves quality and effectiveness by examining interactions, processes, tools and completion practices. Its one-month-Sprint maximum is three hours. Shorter Sprints normally use shorter planning/review/retrospective events; Daily Scrum remains 15 minutes.
- Only the Product Owner has authority to cancel a Sprint, for example when its goal becomes obsolete. A difficult day or new stakeholder request does not automatically justify cancellation.
Artifacts, commitments and product value
| Artifact | Commitment | Decision cue |
|---|---|---|
| Product Backlog | Product Goal | Evolving ordered product work toward a longer-term objective. |
| Sprint Backlog | Sprint Goal | Developers' selected work and adaptable plan for one coherent purpose. |
| Increment | Definition of Done | Usable product progress meeting shared quality requirements. |
- Finish or abandon a Product Goal before taking on another. The Product Backlog emerges with learning; refinement is an ongoing activity, not a prescribed separate Scrum event.
- A Sprint Goal provides coherence and flexibility in exact implementation. Developers update the Sprint Backlog throughout the Sprint; changes must not undermine the goal.
- Work that fails the Definition of Done is not part of a completed Increment. It returns to the Product Backlog for future consideration rather than being counted done with a promise to test later.
- Multiple Increments can be created and delivered during a Sprint. Release need not wait for the Sprint Review. Multiple teams on one product must agree on and follow the same Definition of Done and work toward the same Product Goal/Product Backlog under one Product Owner.
- Value is an outcome for users/organization, not merely story points or utilization. Forecasts use empirical evidence and uncertainty; velocity is not a cross-team productivity score. Burn charts, user stories and estimation techniques can help but are not prescribed framework requirements.
Traps
- Self-management does not mean ignoring goals, quality or organizational standards.
- A Sprint Review is not a phase-gate approval meeting; the Daily Scrum is not the only time Developers may coordinate.
- Quality is not traded away to inflate a completion percentage.
Final active recall
1. Which commitment belongs to each artifact?
Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done.
2. Who can cancel a Sprint?
The Product Owner, when cancellation is appropriate, such as an obsolete Sprint Goal.
3. Can an Increment be released before Sprint Review?
Yes, if it meets the Definition of Done and relevant release conditions; the Review is not the release gate.
4. Does Scrum require user stories and story points?
No. They are optional techniques, not required framework elements.
5. A feature works but has not met the Definition of Done. Count it in the Increment?
No. It is not completed Increment work; make the unfinished status transparent.
Sources and further practice
- Official exam scope
- Objective-to-topic coverage map. Each full topic links to its supporting primary technical documentation.
- 2020 Scrum Guide
- Scrum.org professional competencies
Framework explanation adapted from the 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland under CC BY-SA 4.0. Changes: condensed wording, original examples and recall scenarios. This quick review and the five Scrum chapters are offered under CC BY-SA 4.0; unrelated site content and artwork are excluded.
Every topic at a glance
Open any topic to revisit its essential facts, decisions and exam traps. Use the full topic for active recall and supporting references.
01 · Empiricism, Values and Adaptation
Memory hook: Make reality visible, inspect it, change the plan.
Must remember
Scrum supports complex work where the full solution cannot be predicted upfront. Empiricism learns from observed evidence; lean thinking reduces waste. Transparency makes the actual state understandable, inspection checks it, and adaptation changes the response. Hiding unfinished work undermines every later decision.
The five values are commitment, focus, openness, respect and courage. Commitment is to goals and professional collaboration, not a promise that uncertainty will disappear. Courage includes exposing bad news; respect includes trusting capable people while addressing real problems.
Iterative work revisits and improves understanding; incremental work adds usable value. A team can run frequent meetings yet fail to inspect a real usable product. Choose a next action that improves evidence and value, not one that preserves an attractive report.
Scenario drill: a team marks untested items complete to avoid an uncomfortable review. Correct the meaning of completion, expose the actual state, and adapt scope or the delivery approach. Suppressing the test results makes the forecast less useful, not more reliable.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Unknown customer response | Run a small useful experiment and inspect evidence. |
| Hidden unfinished work | Restore transparency before trusting the forecast. |
| Inspection finds a harmful practice | Adapt promptly rather than repeating it unchanged. |
Traps
- Scrum is not a detailed step-by-step project plan.
- Doing events mechanically does not guarantee empirical learning.
02 · Accountabilities and Self-Managing Teams
Memory hook: Owner orders value; Developers plan delivery; Master enables effectiveness.
Must remember
The Scrum Team contains a Product Owner, Scrum Master and Developers. It is cross-functional and self-managing, typically ten or fewer people. Cross-functional means the team collectively has/acquires the skills to create value; every individual need not be an expert in every discipline.
The Product Owner is accountable for product value and effective Product Backlog management. Work can be delegated, but accountability remains. One person holds this accountability; a stakeholder committee does not replace it. Developers decide how to do the work, maintain the Sprint plan and uphold quality. They are not limited to people with a programmer job title.
The Scrum Master helps establish Scrum and improve team effectiveness through teaching, coaching, facilitation and removing organizational impediments. This is leadership, not automatically line management or task allocation. Stakeholder pressure does not authorize the Scrum Master to dictate estimates or override the Product Owner’s ordering.
Self-management works within organizational goals and standards. Help the team solve its own problem when possible; act on barriers outside its reach. A team needing help is not evidence that a manager should permanently take over every decision.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Who orders product work? | Product Owner, with input and retained accountability. |
| Who decides implementation? | Developers doing the work. |
| Organization blocks collaboration | Scrum Master helps remove the systemic barrier. |
Traps
- Delegating backlog work does not delegate Product Owner accountability.
- Self-management is not isolation from stakeholders or standards.
03 · Sprints and Purposeful Events
Memory hook: Plan the goal; adapt daily; inspect value; improve the way of working.
Must remember
The Sprint contains the other events and lasts one month or less. A new Sprint follows immediately. Do not extend it to make the forecast appear correct. Only the Product Owner may cancel a Sprint when its goal becomes obsolete. Scope can be renegotiated as learning occurs, without endangering the Sprint Goal or reducing quality.
Sprint Planning addresses why the Sprint is valuable, what can be completed and how to approach it. The whole team collaborates; Developers select work in discussion with the Product Owner and own their plan. Maximum Planning time is eight hours for a one-month Sprint, usually less for shorter Sprints.
The Daily Scrum is a 15-minute Developers’ event to inspect progress toward the Sprint Goal and adapt the plan. It is not a status report to the Scrum Master, and the old three-question format is not mandatory. Further problem solving can happen outside it.
The Sprint Review inspects the result and changes with stakeholders to decide useful adaptations; it is not merely a demo or release approval gate. The Retrospective improves quality and effectiveness of the team’s way of working. For a one-month Sprint their maximum timeboxes are four and three hours respectively, usually shorter for shorter Sprints.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| New learning changes needed tasks | Developers adapt the plan with appropriate Product Owner collaboration. |
| Stakeholders inspect product outcomes | Sprint Review. |
| Team improves its collaboration | Sprint Retrospective. |
Traps
- A release need not wait for the Review.
- Sprint scope is adaptable; the Sprint Goal provides coherence.
04 · Artifacts, Commitments and Done
Memory hook: Product Goal, Sprint Goal, Definition of Done.
Must remember
The Product Backlog is the evolving ordered source of product work; its commitment is the Product Goal. The Sprint Backlog combines the Sprint Goal, selected work and delivery plan; its commitment is the Sprint Goal. The Increment is usable integrated value; its commitment is the Definition of Done.
The Product Goal gives longer-term direction. The team finishes or abandons it before adopting another. Refinement continuously adds clarity and suitable size to upcoming work; it is not a prescribed formal Scrum event. User stories, story points and a Definition of Ready are optional techniques, not mandatory framework elements.
The Definition of Done establishes shared quality expectations. Work that does not meet it cannot count as part of the Increment. Teams working on one product must agree on and follow the same Definition of Done, meeting organizational minimums. Acceptance criteria for an individual item do not replace product-wide quality requirements.
Multiple Increments can be created/released within a Sprint. Finished work should integrate with prior work. Unfinished items return to the Product Backlog for future consideration; they are not automatically counted as completed or blindly carried into a guaranteed future scope.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Work coded but required tests fail | It is not Done. |
| Different teams build one product | Shared product direction/backlog and mutually defined Done standard. |
| Need clarity on upcoming work | Continuous refinement. |
Traps
- Acceptance criteria and Definition of Done solve related but different problems.
- Scrum does not require story points.
05 · Product Value, Forecasting and Coaching
Memory hook: Forecast from evidence; coach decisions; measure outcomes.
Must remember
A useful forecast considers observed delivery, available capacity, dependencies and uncertainty. Velocity can help one team plan when used consistently, but comparing teams by points encourages distorted estimates. A forecast is not a guarantee and should change when evidence changes.
Value depends on users and outcomes. Release small useful increments, inspect adoption and feedback, and reorder work accordingly. A large backlog is not evidence of success. Product Owner decisions weigh opportunity, risk, learning, dependencies and stakeholder needs; the loudest requester does not automatically get the next item.
Facilitation helps a group reach a useful result without taking over its substantive decisions. Coaching builds the team’s ability to think and act; teaching explains Scrum or a skill; mentoring shares relevant experience. Select the stance the situation needs. Intervening directly may help an urgent external impediment, while routine task choices belong to the team.
For a scenario, identify the threatened goal, missing transparency and correct accountability. Favor an action that restores learning and self-management. Avoid reflex answers such as adding a manager, extending the Sprint, lowering Done or shielding the Product Owner from all stakeholders.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Team estimates inflated to hit a target | Remove misuse of the metric and return to honest evidence. |
| Unclear user benefit | Test an outcome hypothesis with users. |
| Developers seek permission for every task | Coach self-management within clear goals and standards. |
Traps
- More features do not necessarily mean more value.
- A Scrum Master should not become a permanent approval bottleneck.