Try 10 focused CSM questions on Events & Timeboxes, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | CSM |
| Topic area | Events & Timeboxes |
| Blueprint weight | 23% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Events & Timeboxes for CSM. 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: 23% 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: Events & Timeboxes
In the Sprint Retrospective, the Scrum Team selects two improvement actions to reduce unfinished work at the end of each Sprint. They want to keep the actions few, high-impact, and easy to inspect.
Which is the best evidence that the improvement actions are working?
Best answer: B
What this tests: Events & Timeboxes
Explanation: Improvement actions are validated by inspecting outcomes in subsequent Sprints, not by producing plans or changing tools. Evidence should show increased delivery of a Done Increment toward the Sprint Goal and a measurable reduction in the problem the team targeted (unfinished work). This enables clear inspection and adaptation in the next Retrospective.
In Scrum, Retrospective improvements should be small in number, high-impact, and made transparent so the team can inspect whether they change outcomes. The strongest indicator is observable results in the next Sprint(s), such as achieving the Sprint Goal with more work meeting the Definition of Done and less unfinished work carried over.
A practical way to track is:
Plans, extra meetings, and board reformatting can support the work, but they do not by themselves validate that the improvement produced better outcomes.
It validates improvement through an inspected outcome (more Done work and Sprint Goal achievement), not just activity.
Topic: Events & Timeboxes
During the Sprint Review for a consumer web app, stakeholders see the latest Increment and request: “Add single sign-on (SSO) next Sprint; our enterprise prospects are asking for it.” The Product Owner feels pressure to agree immediately.
What is the best question to ask first before deciding how to handle this request?
Best answer: C
What this tests: Events & Timeboxes
Explanation: In the Sprint Review, new ideas are welcome, but the key is to inspect outcomes and adapt the Product Backlog based on value. The first step is to understand the stakeholder’s underlying need and urgency so the Product Owner can decide how (or whether) to adjust ordering toward the Product Goal. Commitment and assignment decisions come after clarifying what value is being requested.
A Sprint Review is for inspecting the Increment with stakeholders and adapting the Product Backlog based on what was learned. When a new request emerges, the Product Owner should first clarify the stakeholder need (the problem/opportunity, expected outcomes, and urgency) so it can be translated into Product Backlog items and ordered against other work in service of the Product Goal.
A useful first check is:
Only after the request is understood should the Scrum Team discuss options, size/complexity, and sequencing. The key takeaway is to learn and adapt collaboratively, not to make immediate delivery commitments in the Review.
Clarifying the stakeholder need and urgency enables adapting the Product Backlog ordering to maximize value.
Topic: Events & Timeboxes
A distributed Scrum Team meets on a video call for the Daily Scrum, but people mostly give verbal status updates and the call often runs over 15 minutes. After the meeting, they notice surprises during the day.
Exhibit: Sprint Backlog snapshot (today)
Sprint Goal: "Enable customers to reset passwords"
SB-12 Build reset API | In Progress | last update: 4 days ago
SB-13 Update UI flow | In Progress | last update: 3 days ago
SB-15 Fix email token bug | In Progress | last update: 5 days ago
SB-16 Add automated tests | To Do | last update: 6 days ago
Based on the exhibit, what is the best next action to keep the Daily Scrum effective for this remote team?
Best answer: B
What this tests: Events & Timeboxes
Explanation: The Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog plan for the next day of work. The exhibit shows stale Sprint Backlog information, which reduces transparency and makes inspection/adaptation ineffective. Using the shared Sprint Backlog live (and keeping it current) helps a remote team focus the event and make concrete coordination decisions quickly.
To keep a remote Daily Scrum effective, anchor the conversation on a transparent Sprint Backlog and the Sprint Goal, not on individual status reporting. In the exhibit, multiple items have been “In Progress” with no updates for days, which signals low transparency and makes it hard to inspect progress and adapt the plan.
A practical next step is for the Developers to:
This preserves the purpose of the event and helps distributed coordination without increasing the timebox.
A shared, up-to-date Sprint Backlog lets Developers inspect progress toward the Sprint Goal and adapt their plan within the 15-minute Daily Scrum.
Topic: Events & Timeboxes
During the Daily Scrum, the Developers inspect progress toward the Sprint Goal and notice the following Sprint Backlog excerpt.
Exhibit: Sprint Backlog (excerpt)
Sprint Goal: Password reset available in production
- PBI-15 Send reset email (In Progress)
Blocker: SMTP credentials expired; emails cannot be sent
- PBI-18 Token validation API (Not Started)
- Task: Automated tests (Not Started)
What is the best next action for how the Sprint Backlog should be updated based on this daily inspection?
Best answer: D
What this tests: Events & Timeboxes
Explanation: The Sprint Backlog is a plan by and for the Developers, and it is expected to emerge and change throughout the Sprint. After daily inspection at the Daily Scrum, the Developers adapt their plan by updating the Sprint Backlog to reflect newly discovered work and obstacles while keeping focus on the Sprint Goal.
At the Daily Scrum, the Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed. Because the exhibit shows a concrete blocker preventing email sending, the plan is incomplete unless it includes the work to remove that blocker (and any resulting sequencing changes). Updating the Sprint Backlog can include adding tasks, changing task order, revising estimates, and making the blocker visible so the Developers can coordinate next steps. If the new information puts achieving the Sprint Goal at risk, the Developers collaborate with the Product Owner to negotiate scope, but the immediate outcome of the Daily Scrum is an updated plan in the Sprint Backlog. The key is adapting the plan daily, not waiting for a later event.
The Sprint Backlog is the Developers’ plan, and daily inspection should result in updating it with new tasks/changes needed to meet the Sprint Goal.
Topic: Events & Timeboxes
In the Sprint Retrospective, the Scrum Team agrees on one improvement action: “add an automated unit-test step to the CI pipeline.” The Developers believe it will take about a day of work.
The Product Owner wants the next Sprint to focus on a new customer feature, and the Scrum Team wants to incorporate the improvement without derailing delivery.
Which approach should the Scrum Team NOT use?
Best answer: A
What this tests: Events & Timeboxes
Explanation: Retrospective improvements are valuable, but they must be incorporated transparently through planning and ongoing inspection. The Sprint Backlog is a plan by and for the Developers, and changes during the Sprint should be managed in a way that protects focus on the Sprint Goal. Mandating mid-Sprint additions “no matter what” is the anti-pattern that derails delivery.
Improvement actions from the Sprint Retrospective are often implemented in the next Sprint, but Scrum does not require them to be done immediately or at the expense of the Sprint Goal. To incorporate an improvement without derailing delivery, make it transparent and deliberate by including it in the Sprint forecast and managing trade-offs.
Acceptable ways include:
The key takeaway is that improvement work should be planned and adapted within the Sprint’s purpose, not forced in as “mandatory” regardless of impact.
Forcing unplanned improvement work into the Sprint Backlog mid-Sprint without considering the Sprint Goal undermines the Sprint forecast and creates churn.
Topic: Events & Timeboxes
During Sprint Planning, the Product Owner proposes a high-priority Product Backlog item: “Add single sign-on (SSO) for the customer portal.” The Scrum Team’s Definition of Done is already established and understood.
The Developers start discussing tasks and whether the item can fit in the Sprint, but they realize they don’t know what “SSO” must support or how success will be validated.
What should the Scrum Team clarify first to plan effectively?
Best answer: B
What this tests: Events & Timeboxes
Explanation: In Sprint Planning, the Scrum Team needs enough understanding of the selected Product Backlog items to create a workable plan. Clarifying acceptance criteria (and how it will be validated) makes the expected outcome transparent so the Developers can decompose the work and make a realistic forecast. With the Definition of Done already understood, the biggest immediate gap is what “acceptable” means for this item.
Effective Sprint Planning depends on having the right information to create a meaningful Sprint Backlog plan. If the Definition of Done is already established, the next critical planning input for a specific Product Backlog item is its acceptance criteria: what behavior, constraints, and checks will demonstrate it meets the stakeholder need. That clarity enables the Developers to decide what work is required, identify likely dependencies as they break it down, and forecast whether it can be completed within the Sprint while still meeting the Definition of Done. Planning based on past velocity, detailed assignments, or reporting preferences does not resolve the core uncertainty about what must be built and how it will be validated.
Without clear acceptance criteria, the team cannot reliably break down, estimate, or forecast the work for the Sprint.
Topic: Events & Timeboxes
For the last three Sprint Retrospectives, the Developers either blamed a specific person for issues or concluded there was “nothing to improve.” The Scrum Master coached the team to pick one small improvement each Sprint and try it.
Which evidence best validates that the Retrospective is now leading to meaningful improvement?
Best answer: D
What this tests: Events & Timeboxes
Explanation: A Sprint Retrospective creates value only when the Scrum Team identifies improvements and puts at least one into practice. The strongest validation is an implemented improvement that can be observed in outcomes such as product quality, flow, or the team’s ability to meet the Sprint Goal. Outputs like notes, attendance, or idea lists are not evidence of change.
A common Retrospective anti-pattern is treating it as a discussion (or blame session) with no follow-through, or concluding “nothing to improve.” In Scrum, the Retrospective’s purpose is to plan ways to increase quality and effectiveness, which requires turning insights into concrete changes and validating them through empiricism.
Good validation focuses on outcomes:
Observable effects like fewer defects, smoother integration, or reduced rework demonstrate that the Retrospective is driving real improvement; ceremony-focused artifacts and activity metrics do not.
It shows an improvement was actually tried and produced an observable quality outcome, not just discussion.
Topic: Events & Timeboxes
During the Daily Scrum, the Developers report that the staging environment is down and they cannot run the tests needed to finish the Product Backlog Items they forecast for the Sprint. The issue is outside the team’s control (owned by another internal group) and is likely to block progress today.
What is the most appropriate immediate next step?
Best answer: C
What this tests: Events & Timeboxes
Explanation: The Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours. When an external impediment is discovered that blocks progress, the team should make it transparent and then take action immediately after the event, leveraging the Scrum Master to help remove it.
In Scrum, the Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed. When an impediment is identified—especially one outside the Developers’ control and blocking work today—the immediate Scrum-aligned response is to finish the Daily Scrum (keeping its purpose and timebox intact) and then act right away.
A practical next step is:
This preserves the Daily Scrum’s intent while enabling fast impediment removal and continued progress toward the Sprint Goal.
The Developers use the Daily Scrum to replan for the next day, then work with the Scrum Master right after to remove an impediment that is blocking progress.
Topic: Events & Timeboxes
During the Daily Scrum on day 5 of a 10-day Sprint, the Developers review the Sprint Backlog and discover an impediment.
Exhibit: Sprint board (excerpt)
Sprint Goal: Customers can reset passwords via email link
PBIs: PBI-12 Reset flow | PBI-15 Email template
Work:
- T-31 Implement reset token API (In Progress)
- T-34 Integrate email service (Blocked: SMTP access)
- T-36 Automated tests for reset flow (To Do)
What is the most appropriate immediate next step?
Best answer: C
What this tests: Events & Timeboxes
Explanation: In the Daily Scrum, the Developers inspect progress toward the Sprint Goal and adapt their plan for the next 24 hours. With work blocked by missing SMTP access, they should immediately adjust their plan to keep moving toward the Sprint Goal while making the impediment visible so it can be removed quickly.
The Daily Scrum’s purpose is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed. When an impediment is discovered (here, SMTP access blocking email integration), the immediate action is to replan the next day’s work so the team can still make progress toward the Sprint Goal (for example, shift to the API and tests or other unblocked work). In parallel, the impediment should be made transparent and the Scrum Master can help remove it by working with the organization or external parties.
Key takeaway: don’t turn the Daily Scrum into an escalation meeting or a task assignment session; use it to adapt the plan and surface impediments.
Developers adapt the Sprint Backlog for the next day and leverage the Scrum Master to help remove the impediment.
Topic: Events & Timeboxes
A Scrum Team is about to start Sprint Planning. The Product Owner says they cannot attend and asks the Developers to “pick the work and send me the plan to approve later.” Several stakeholders also request to join Sprint Planning to “make sure the team commits to the right scope.”
As Scrum Master, what should you clarify first before deciding who should participate in Sprint Planning?
Best answer: D
What this tests: Events & Timeboxes
Explanation: Sprint Planning is for the Scrum Team: the Product Owner and Developers participate, and the Scrum Master ensures the event happens and is effective. The Product Owner contributes by explaining the most valuable work and collaborating on a Sprint Goal, while Developers contribute by forecasting what they can do and creating a plan. Clarifying the Product Owner’s participation is the first step because it directly affects the team’s ability to form a coherent Sprint Goal and select work.
In Scrum, Sprint Planning is an event for the Scrum Team. The Product Owner and Developers must be able to collaborate to decide why the Sprint is valuable (Sprint Goal), what can be done (selected Product Backlog Items), and how the work will be performed (the plan). If the Product Owner is absent and expects to approve later, the team loses timely product direction, trade-off decisions, and shared understanding needed to create a meaningful Sprint Goal.
A practical first clarification is whether the Product Owner (or someone acting with that accountability) can participate during Sprint Planning to:
Stakeholders may be invited if they can provide helpful input, but they are not required participants and should not be positioned as approvers of the Sprint plan.
Sprint Planning requires the Product Owner and Developers to collaborate, with the Product Owner providing Product Backlog context and working with Developers on the Sprint Goal.
Use the CSM Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the CSM guide on PMExams.com, then return to PM Mastery for timed practice.