Try 10 focused PSM I questions on Scrum Events and Timeboxes, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | PSM I |
| Topic area | Scrum Events and Timeboxes |
| Blueprint weight | 25% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Scrum Events and Timeboxes for PSM I. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 25% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Scrum Events and Timeboxes
In the Sprint Retrospective, the Scrum Team agrees that their biggest problem is frequent production defects caused by missing automated regression tests. They identify one improvement action: add a basic automated regression test stage to the CI pipeline, estimated at about one day of work.
Sprint Planning for the next Sprint starts now, and the Product Owner wants to maximize new features. What is the best Scrum-aligned way to incorporate this improvement action into the next Sprint?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Retrospective produces improvement actions, and the most valuable improvements should be addressed as soon as practical. The next Sprint is planned in Sprint Planning, where the Scrum Team can include improvement work in the Sprint Backlog and negotiate scope so the Sprint Goal remains achievable while quality improves.
Improvement actions from the Sprint Retrospective are part of empiricism: the team inspects how it worked and adapts its way of working. In Scrum, those improvements are made transparent by incorporating them into the plan for the next Sprint, typically as items in the Sprint Backlog.
In Sprint Planning, the Developers forecast what they can accomplish toward a Sprint Goal. If an improvement (like adding automated regression tests) is important to increase quality and reduce rework, the Scrum Team should plan it into the Sprint, adjusting scope as needed rather than treating it as “extra” work. The Product Owner can help by discussing trade-offs and value, but improvements should not be hidden or deferred solely to maximize features.
The key takeaway is to plan improvement work explicitly into the next Sprint’s plan.
Retrospective improvements can be planned into the next Sprint as Sprint Backlog work, with scope negotiated to protect quality and the Sprint Goal.
Topic: Scrum Events and Timeboxes
Mid-Sprint, the Developers switch their Daily Scrum to a “walk the board” conversation focused on the Sprint Goal. The Scrum Master asks how they will know this Daily Scrum structure is effective.
Which is the best evidence that the Daily Scrum structure is valid in Scrum?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: A valid Daily Scrum structure is one that helps the Developers inspect progress toward the Sprint Goal and adapt their plan for the next day. The clearest evidence is a changed or confirmed plan in the Sprint Backlog that increases the likelihood of meeting the Sprint Goal.
In Scrum, the Daily Scrum’s purpose is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. Scrum does not require a specific format (like “three questions”); any structure is valid if it improves transparency and enables inspection and adaptation.
The strongest indicator that a Daily Scrum is working is that it produces actionable planning outcomes:
Timeboxing and consistent attendance support the event, but they do not validate that the Daily Scrum is enabling empiricism and progress toward the Sprint Goal.
The Daily Scrum is effective when it results in inspecting progress toward the Sprint Goal and adapting the plan in the Sprint Backlog.
Topic: Scrum Events and Timeboxes
During Sprint Planning for a 2-week Sprint (timeboxed to 2 hours), the Scrum Team drafts a Sprint Goal: “Enable customers to sign up with email.” A stakeholder joins briefly and shares new information: a consent checkbox and stored timestamp are now required for legal compliance. Without it, the feature cannot meet the team’s Definition of Done and cannot be released.
The Developers estimate the consent work will likely consume about half of their Sprint capacity. What is the BEST next action?
Best answer: D
What this tests: Scrum Events and Timeboxes
Explanation: Sprint Planning is where the Scrum Team adapts the plan based on the latest information while staying within the timebox. Because the new compliance requirement affects the ability to meet the Definition of Done, it must be made transparent and incorporated into the Product Backlog. The Product Owner and Developers then adjust selection and possibly the Sprint Goal so a Done Increment remains realistic.
When new information is discovered during Sprint Planning, the Scrum Team should use it to adapt rather than “lock” a plan. Here, the consent requirement changes what it means to deliver a Done, releasable Increment, so it must be made transparent and reflected in the Product Backlog.
A good next step is to:
The key takeaway is to adapt scope and/or the Sprint Goal with the Product Owner, not to hide work, delegate decisions to the Scrum Master, or extend the timebox.
New information should be made transparent and used to adapt the Product Backlog and Sprint plan with the Product Owner so the team can meet the Definition of Done within the timebox.
Topic: Scrum Events and Timeboxes
A Scrum Team just finished the Sprint Review. Stakeholders accepted the Increment, but several defects were found late in the Sprint and the team struggled to collaborate on fixing them. The Product Owner asks how the team will prevent this from happening again.
What is the best next step?
Best answer: A
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Retrospective is the Scrum event dedicated to inspecting how the last Sprint went and deciding what to change. It should produce a small set of actionable improvements that the Scrum Team can implement as soon as possible, often starting in the next Sprint. This directly addresses recurring defects and collaboration problems through inspection and adaptation.
The Sprint Retrospective’s purpose is to plan ways to increase quality and effectiveness by inspecting how the last Sprint went (people, interactions, processes, tools, and the Definition of Done) and adapting accordingly. In this situation, the key problem is late-discovered defects and poor collaboration on fixing them, so the best next step is to use the Retrospective to identify root causes and agree on concrete experiments or changes.
Typical outcomes are:
This keeps improvement work inside Scrum rather than adding external governance or skipping the inspect/adapt step.
The Sprint Retrospective exists to inspect how the Sprint went and create an actionable plan to improve the team’s effectiveness and quality next Sprint.
Topic: Scrum Events and Timeboxes
Which statement best explains the three topics of Sprint Planning (why, what, how) and their intent?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: Sprint Planning addresses three topics to create focus and a workable plan for the Sprint. The Scrum Team first aligns on why the Sprint is valuable (Sprint Goal), then decides what can be done (a forecast selected from the Product Backlog), and finally plans how the work will be accomplished (details in the Sprint Backlog).
In Scrum (2020), Sprint Planning creates the plan for the Sprint by covering three topics that build on each other.
These topics ensure the Sprint has a clear purpose, a realistic forecast, and enough planning detail to start execution while still allowing adaptation during the Sprint.
Sprint Planning aligns on the Sprint Goal, forecasts work from the Product Backlog, and plans how to achieve it in the Sprint Backlog.
Topic: Scrum Events and Timeboxes
A Scrum Team’s Sprint Planning regularly consumes the full 8-hour timebox for a one-month Sprint. The Developers insist on breaking every Product Backlog item into hour-by-hour tasks and debating the “best” sequence for all work before they will start the Sprint.
The Product Owner brings an ordered Product Backlog with clear acceptance criteria, and the team’s Definition of Done is well understood. At the end of Sprint Planning, the team can describe the tasks but struggles to explain why the selected work matters.
What is the most likely underlying cause in Scrum terms?
Best answer: C
What this tests: Scrum Events and Timeboxes
Explanation: Sprint Planning is being used to reduce uncertainty by exhaustively detailing tasks, but the team cannot explain the “why” for the Sprint. In Scrum, that “why” is the Sprint Goal. When it is unclear or missing, teams often compensate with excessive task-level planning instead of aligning on a shared objective and a workable plan to achieve it.
Sprint Planning should result in a clear Sprint Goal and a workable plan (Sprint Backlog) to achieve it, not an attempt to predict and optimize every hour of the Sprint. In the scenario, acceptance criteria are clear and the Definition of Done is well understood, so quality expectations and item clarity are not the main constraint. The key symptom is that the team finishes with detailed tasks but cannot articulate why the selected work matters.
A missing or unclear Sprint Goal removes alignment and decision-making guidance, so the team tries to create safety through over-detailed task breakdown and sequencing. A clear Sprint Goal enables “just enough” planning so the Developers can start, inspect progress daily, and adapt the plan throughout the Sprint.
Without a clear Sprint Goal, the team over-plans tasks to create certainty instead of aligning on a coherent objective for the Sprint.
Topic: Scrum Events and Timeboxes
Which option best reflects an effective improvement action that a Scrum Team should create during the Sprint Retrospective?
Best answer: C
What this tests: Scrum Events and Timeboxes
Explanation: Sprint Retrospective outcomes are improvements the Scrum Team will act on to increase quality and effectiveness. The best improvements are small enough to be started quickly (often in the next Sprint) and are clearly owned by the Scrum Team. This supports empiricism by enabling rapid inspection and adaptation of the team’s way of working.
In Scrum, the Sprint Retrospective is used to plan ways to increase quality and effectiveness. That planning results in improvement actions that are concrete and doable, not just aspirational themes or someone else’s to solve. A good improvement action is small enough to start soon, specific enough to be observable, and owned by the Scrum Team (even if they collaborate with others).
A practical check is:
The closest distractors tend to shift ownership outside the Scrum Team or make the action too broad to execute.
Retrospective improvements should be actionable, owned by the Scrum Team, and implementable quickly to increase effectiveness.
Topic: Scrum Events and Timeboxes
A Scrum Team’s last three Sprint Retrospectives have raised the same issue: “Our build breaks several times a week, so we lose time and ship defects.” Each time, the team agrees it is important but no one owns an improvement and nothing changes.
This Retrospective, the Developers decide to add “Stabilize CI build” as a visible item in the next Sprint Backlog, with a clear owner and a Daily Scrum check on progress.
What is the most likely near-term impact of this change?
Best answer: D
What this tests: Scrum Events and Timeboxes
Explanation: Turning a recurring Retrospective topic into a clear, owned Sprint Backlog item increases transparency and enables daily inspection and adaptation. That makes it much more likely the team will actually address the repeated issue in the next Sprint, rather than just discussing it again. In the near term, this supports better quality outcomes by following through on improvement work.
A common Sprint Retrospective anti-pattern is identifying the same problems repeatedly without clear ownership or a concrete plan, which prevents adaptation. A practical correction is to create a specific improvement with an owner and make it visible so progress can be inspected during the Sprint (for example, via the Sprint Backlog and Daily Scrum).
By placing “Stabilize CI build” in the Sprint Backlog, the Developers make improvement work transparent and actionable. Daily inspection makes it more likely they will adapt their plan and complete the improvement, which reduces recurring quality and flow disruptions. The key takeaway is that improvement needs ownership and visibility to avoid “same issues, no change.”
Making a concrete, owned Sprint Backlog item creates transparency and frequent inspection, increasing follow-through on the recurring problem.
Topic: Scrum Events and Timeboxes
A stakeholder asks to join the upcoming Sprint Retrospective “to ensure the team fixes its process issues.” The Product Owner agrees, but several Developers say they will not speak openly if the stakeholder attends. As Scrum Master, what is the first thing you should clarify before deciding who will participate?
Best answer: D
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Retrospective is an event for the Scrum Team to inspect and adapt its effectiveness and plan improvements. The default participants are the Scrum Team (Product Owner, Scrum Master, and Developers). Others may be invited only if the Scrum Team believes their presence will help achieve the Retrospective’s purpose without reducing openness and transparency.
In Scrum, the Sprint Retrospective is where the Scrum Team inspects how the last Sprint went (people, interactions, processes, tools, Definition of Done) and identifies the most useful improvements to try next. Because it depends on candor and psychological safety, participation is centered on the Scrum Team: the Product Owner, Scrum Master, and Developers.
If someone outside the Scrum Team wants to attend, the right first check is whether the Scrum Team wants that person invited and why (what specific information or collaboration is needed). The Scrum Master helps the team understand the event’s purpose and protects the conditions for transparency; inviting others is a deliberate choice, not an automatic right of stakeholders or managers.
Questions about Sprint results, the Definition of Done, or Product Backlog ordering may be discussed later, but they don’t determine who should participate.
The Retrospective is for the Scrum Team to inspect and adapt how it works, and only the Scrum Team decides if inviting others would help.
Topic: Scrum Events and Timeboxes
A Scrum Team’s Sprint Retrospective has turned into a recurring complaint session with no changes carried into the next Sprint. The Scrum Master is considering changing the event’s format.
What is the best question to ask the Scrum Team first to clarify what the Sprint Retrospective is for?
Best answer: A
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Retrospective’s purpose is to plan ways to increase quality and effectiveness by inspecting the last Sprint’s work and collaboration. A good first clarifying question focuses the team on generating actionable improvements they will actually adopt in the next Sprint. This addresses the described problem (no follow-through) without changing Scrum’s intent for the event.
The Sprint Retrospective is a Scrum event for the Scrum Team to inspect how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done, and then to plan improvements. It should produce a concrete improvement plan that the team can act on right away, often by adding the most valuable improvements into the next Sprint Backlog.
A first clarifying question should therefore focus the team on the intended outcome: agreed, actionable changes that increase quality and effectiveness in the next Sprint. Questions centered on stakeholder satisfaction or Product Backlog ordering primarily belong to other accountabilities/events and won’t directly address the Retrospective’s purpose.
The Sprint Retrospective exists to inspect how the last Sprint went and create a plan for improvements to be enacted in the next Sprint.
Use the PSM I Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the PSM I guide on PMExams.com, then return to PM Mastery for timed practice.