Scrum Events and Sprint Cadence

Introduction

Scrum is an empirical framework for developing, delivering, and sustaining complex products. Its events create a regular rhythm in which a Scrum Team inspects its work and context, adapts its plan, and produces a usable Increment. The events are therefore not merely meetings. They are formal opportunities for transparency, inspection, and adaptation.

A Sprint provides the basic cadence of Scrum. During a fixed period—normally one month or less—the Developers create a usable, valuable product Increment. Sprint Planning begins the Sprint, the Daily Scrum supports day-to-day adaptation, the Sprint Review examines the outcome with stakeholders, and the Sprint Retrospective identifies improvements to the way the team works. The next Sprint begins immediately after the previous Sprint ends.

Effective event management requires more than observing a clock. The Scrum Master helps participants understand the purpose of each event, protects the event from becoming unfocused, encourages meaningful participation, and supports decisions based on evidence. However, facilitation must not turn the Scrum Master into a meeting chair who owns all decisions. Product decisions remain with the Product Owner, technical decisions remain with the Developers, and the Scrum Team jointly owns the Sprint goal and the quality of its work.

Learning Objectives

By the end of this chapter, learners should be able to:

• explain the purpose, participants, inputs, outputs, and timeboxes of the principal Scrum events;
• plan a Sprint around a coherent Product Goal and Sprint Goal;
• facilitate collaborative and concise Sprint Planning;
• distinguish the Daily Scrum from a status-reporting meeting;
• organize a useful Sprint Review based on product evidence and stakeholder dialogue;
• conduct a psychologically safe Sprint Retrospective that leads to actionable improvement;
• manage interruptions, incomplete work, dependencies, and disagreement during a Sprint; and
• evaluate whether a team’s cadence supports transparency, inspection, adaptation, and value delivery.

1. Scrum Cadence as an Empirical Control System

Scrum assumes that complex product development cannot be managed reliably through detailed prediction alone. Requirements, technology, customer expectations, and organizational conditions change. A team therefore works in short cycles, obtains evidence from the Increment, and adjusts its next decisions.

The cadence can be understood as a repeating control loop:

1. establish a short-term objective;
2. select and clarify work that may achieve that objective;
3. develop and integrate a usable Increment;
4. inspect the Increment and relevant market or organizational information;
5. reflect on the team’s methods and relationships; and
6. adapt the Product Backlog, working practices, or both.

The five Scrum events are deliberately connected. Sprint Planning should not be treated as an isolated estimation workshop. Its result is a Sprint Goal and a workable plan. The Daily Scrum should not be treated as a manager’s progress inspection. It is a planning and adaptation event for the Developers. The Sprint Review is not simply a demonstration, and the Retrospective is not a complaint session. Each event has a distinct purpose that contributes to the same empirical system.

1.1 The Sprint as a container

The Sprint is a fixed-length container for all other Scrum activities. A consistent length makes performance and learning easier to compare over time. A team might use two-week Sprints, while another product may use one-week or four-week Sprints. The appropriate length depends on product risk, learning needs, release constraints, and the cost of coordination. A Sprint should be short enough that important assumptions are tested before they become expensive, but long enough for the team to produce a meaningful Increment.

A Sprint should not be extended merely because selected work is incomplete. Extending it weakens the cadence and hides the difference between planned and achieved outcomes. Unfinished work is returned to the Product Backlog, where the Product Owner may reorder it after considering its current value and evidence. The Product Owner may cancel a Sprint only when the Sprint Goal becomes obsolete; cancellation is exceptional because it disrupts the learning cycle.

1.2 Timeboxes

A timebox establishes a maximum duration, not a target duration that must always be filled. An event may end earlier when its purpose has been achieved. The maximum durations commonly associated with a one-month Sprint are:

These are maximums, not mandatory allocations. The Scrum Guide does not prescribe a mathematical scaling rule for shorter Sprints. Teams should use judgment while ensuring that the event is long enough to achieve its purpose. For example, halving every event automatically may be unsuitable if the product has many dependencies or stakeholders.

A useful planning relationship is:

Here, T_event is the actual event duration and T_max is the applicable maximum timebox. This is a constraint, not a productivity formula. It does not imply that longer events are better or that all teams should use the maximum.

2. Sprint Planning

Sprint Planning initiates the Sprint by establishing why the Sprint is valuable, what can be accomplished, and how the selected work will be completed. The entire Scrum Team participates. The Product Owner ensures that the most valuable and relevant Product Backlog items are available for discussion. Developers assess feasibility and create the plan. The Scrum Master helps the participants understand the purpose and supports effective facilitation.

Sprint Planning addresses three questions:

1. Why is this Sprint valuable?
2. What can be done during the Sprint?
3. How will the chosen work be completed?

2.1 Preparing for Planning

Good Sprint Planning begins before the event. Preparation may include:

• clarifying the Product Goal and current product strategy;
• ordering the Product Backlog according to value, risk, learning, and dependencies;
• refining likely items sufficiently for discussion;
• identifying acceptance criteria and quality expectations;
• checking team availability, holidays, support duties, and known interruptions;
• making technical, security, legal, or operational constraints visible; and
• ensuring that the previous Increment and relevant stakeholder feedback are available.

Backlog refinement is not a formal Scrum event, but it is a useful ongoing activity. Refinement should not become a second planning meeting in which the team attempts to specify every detail weeks in advance. The aim is to improve shared understanding and reduce avoidable uncertainty.

2.2 Establishing the Sprint Goal

The Sprint Goal is a single objective that gives the Sprint coherence and flexibility. It explains the value the team intends to create, rather than functioning as a list of unrelated tickets. For example, “Enable new customers to complete self-service account verification” is more coherent than “finish tickets 101, 103, 108, and 114.”

A strong Sprint Goal:

• connects to the Product Goal;
• describes a valuable outcome or learning objective;
• helps Developers make trade-offs during the Sprint; and
• remains meaningful even if individual items change.

The Product Owner proposes how the product could increase its value in the Sprint. The Scrum Team then collaborates to formulate the Sprint Goal. The Product Owner does not unilaterally assign a goal, and Developers do not select work without considering product value.

2.3 Selecting work and creating the plan

Developers select Product Backlog items in discussion with the Product Owner. Selection is influenced by value, dependencies, risk, technical feasibility, historical evidence, and available capacity. Selection is not a guarantee that every item will be completed. The team makes a forecast based on current information.

Capacity is useful as a planning consideration, but it is not a promise or a precise productivity measure. A simple capacity estimate can be expressed as:

where D_i is the number of available working days for team member i, H_i is the planned productive hours per day, and A_i is an availability factor between 0 and 1 representing leave, training, support, and other known commitments. The units of C_available are person-hours. This estimate assumes that work can be meaningfully aggregated and that the availability factor is not being used to claim that all time is uninterrupted development time. It is a planning aid, not a formula for determining value or individual performance.

For example, three Developers may each have 8 working days, 6 potentially useful hours per day, and an availability factor of 0.75. The estimated capacity is:

This number should not be converted automatically into a commitment to 108 hours of work. Complexity, collaboration, interruptions, and uncertainty make such precision misleading. Historical completion patterns and current product risk should also inform the forecast.

The team then creates an initial plan for delivering the selected items. Developers may decompose items into tasks, identify integration points, and agree on how testing, documentation, security, accessibility, deployment, and operational work will be handled. The plan should make progress visible without becoming a detailed command-and-control schedule.

2.4 Facilitating effective Sprint Planning

A facilitator can use the following sequence:

1. Reconfirm the Product Goal and review recent evidence.
2. Invite the Product Owner to explain the most valuable current opportunity.
3. Explore candidate items, assumptions, dependencies, and acceptance criteria.
4. Formulate and test a possible Sprint Goal.
5. Ask Developers to assess feasibility and identify risks.
6. Select a coherent forecast of work.
7. Develop an initial delivery plan and surface unresolved questions.
8. Confirm the Sprint Goal, Definition of Done, and immediate next steps.

Participation practices matter. The facilitator should prevent one specialist from dominating, invite quieter participants without forcing them to speak publicly, and separate facts from assumptions. If disagreement concerns product value, the Product Owner leads the product decision. If it concerns implementation, Developers lead the technical decision. If the team lacks information, the appropriate response may be to include a timeboxed experiment or research task rather than pretending that uncertainty has disappeared.

Common failures include turning Planning into ticket assignment, using story points as individual performance targets, overloading the Sprint to satisfy external pressure, and discussing implementation details before agreeing on the objective. These practices reduce ownership and encourage local optimization rather than shared value delivery.

3. The Daily Scrum

The Daily Scrum is a 15-minute event for Developers. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. The event is not a mandatory report to the Scrum Master or Product Owner. Other participants may attend if useful, but Developers should remain the primary participants.

The traditional three questions—what was done yesterday, what will be done today, and what impediments exist—can be useful for inexperienced teams, but they are not the purpose of the event and are not required as a script. A goal-oriented conversation is often more effective:

• What evidence shows progress toward the Sprint Goal?
• What is the most important next work?
• What has changed since the last Scrum?
• Which dependencies, risks, or impediments require action?
• Do we need to change the order, scope, or approach while preserving the goal?

The Daily Scrum should focus on the work and the system, not on individual surveillance. Developers may reorganize tasks, pair on difficult work, swarm around a bottleneck, negotiate a technical approach, or seek assistance after the event. Detailed problem-solving should normally be continued with only the relevant people after the timebox.

3.1 Facilitation techniques

Useful techniques include a Sprint Goal board, a visual flow of work, walking through items closest to completion, and marking blocked work explicitly. A facilitator may ask, “What is preventing this item from meeting the Definition of Done?” rather than “Why has this person not finished?” The former encourages systems thinking; the latter can create defensiveness.

Remote teams need deliberate communication design. A shared board, visible working agreements, reliable audio, and rotating facilitation can improve participation. Chat messages and asynchronous updates may supplement the event but should not silently replace the inspection and adaptation conversation when real-time collaboration is needed.

A Daily Scrum that repeatedly consumes more than 15 minutes may indicate that the team is solving detailed problems in the event, that work is too fragmented, or that impediments are not being addressed elsewhere. A Daily Scrum that ends in two minutes may be healthy if the team has genuinely inspected and adapted, but it may also indicate ritual compliance without meaningful conversation. Duration alone is not a quality measure.

4. Sprint Review

The Sprint Review occurs near the end of the Sprint. The Scrum Team and stakeholders inspect the outcome of the Sprint and collaborate on what to do next. The Product Owner explains the current state of the Product Backlog and discusses likely future adaptations. Developers should demonstrate or otherwise provide evidence of the usable Increment. The event is a working session, not merely a presentation.

The Review should address:

• the Sprint Goal and its intended value;
• what was completed according to the Definition of Done;
• what remains incomplete and why;
• demonstrations, user evidence, operational results, or experiments;
• changes in the market, technology, regulation, or organizational context; and
• possible Product Backlog adaptations and future priorities.

Only work that meets the Definition of Done should be presented as part of the Increment. Incomplete work may be discussed transparently, but it must not be represented as complete. Stakeholders should be invited because they can provide information, challenge assumptions, identify emerging needs, and help evaluate value.

4.1 Designing a useful Review

Preparation begins with identifying the decisions and feedback needed. A team might prepare a scenario-based demonstration, usage data, a usability test result, an operational dashboard, or a prototype experiment. Slides can provide context, but they should not substitute for evidence from the product.

A practical agenda is:

1. welcome participants and state the Sprint Goal;
2. explain the product context and important changes;
3. inspect the usable Increment through demonstration or evidence;
4. discuss outcomes, risks, feedback, and changed assumptions;
5. inspect the Product Backlog and likely next opportunities; and
6. agree on follow-up decisions and ownership.

The Review should not become a ceremonial approval gate controlled by a single manager. Stakeholder feedback is important, but the Product Owner remains accountable for maximizing product value and ordering the Product Backlog. Nor should the event become a performance contest. Demonstrating incomplete work, defects, or disappointing results honestly can produce valuable learning.

5. Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect how the last Sprint went with respect to individuals, interactions, processes, tools, and the Definition of Done. The team identifies the most useful changes and addresses the most significant problems. Improvements may be added to the Sprint Backlog for the next Sprint or incorporated into the team’s working agreements.

Psychological safety is essential. Participants need to be able to discuss mistakes, power differences, overloaded processes, unclear requirements, and harmful behavior without fear of humiliation or retaliation. Psychological safety does not mean avoiding accountability. It means examining causes and conditions so that people can improve the system rather than assigning blame prematurely.

5.1 A practical retrospective structure

A simple structure is:

• Set the stage: restate the purpose, confidentiality boundaries, and working agreements.
• Gather data: collect observations about delivery, quality, collaboration, and external conditions.
• Generate insights: identify patterns, relationships, and likely causes.
• Decide what to do: select one or two high-value improvements.
• Close: confirm owners, success indicators, and when progress will be reviewed.

Possible techniques include “Start, Stop, Continue,” timeline mapping, “Mad, Sad, Glad,” five whys, and a cause-and-effect analysis. Techniques should serve inquiry rather than become entertainment. The facilitator must be alert to cultural differences, hierarchy, language barriers, and the possibility that anonymous input is necessary.

An improvement action should be specific enough to test. “Communicate better” is weak. “For the next Sprint, the on-call Developer joins refinement for production-impacting items, and the team reviews escaped defects at the next Retrospective” is more actionable. The action should have an observable signal, although the team should avoid creating a large measurement bureaucracy.

6. Connecting Events to the Definition of Done and Product Backlog

The Definition of Done is a shared description of the state required for work to be considered complete. It may include coding standards, peer review, automated tests, security checks, accessibility requirements, documentation, integration, and deployment readiness. The Definition of Done protects transparency: an item that does not meet it is not part of the usable Increment.

Events should continuously update the team’s understanding of the Product Backlog. Sprint Planning uses the Product Backlog to select a forecast. The Daily Scrum adapts the Sprint Backlog. The Sprint Review provides stakeholder evidence that may change Product Backlog ordering or content. The Retrospective may create improvement work. These relationships mean that backlog management is not a once-per-Sprint administrative activity.

Useful indicators can support inspection, but metrics must be interpreted carefully. Examples include:

• Sprint Goal outcomes;
• work-item age and blocked time;
• defects discovered after release;
• deployment frequency and recovery time;
• stakeholder feedback;
• proportion of work meeting the Definition of Done; and
• completion of agreed improvement experiments.

Velocity, if used at all, should be treated as a local forecasting aid rather than a universal productivity score. Comparing teams by velocity encourages inflation, gaming, and competition over learning. No single metric captures product value, quality, sustainability, and customer impact.

7. Managing Common Challenges

Interruptions and urgent work

Operational incidents and urgent compliance work may interrupt a Sprint. The team should make the interruption visible, assess its effect on the Sprint Goal, and negotiate scope or sequencing with the Product Owner. A hidden interruption creates a misleading record of performance. Repeated interruptions may justify a capacity buffer, a dedicated support rotation, or changes to the product operating model.

Dependencies

Dependencies should be surfaced before and during Planning. Teams can reduce them through slicing, collaboration, interface agreements, shared integration environments, or architectural simplification. Escalating every dependency to a manager may delay learning; ignoring dependencies is equally harmful.

Incomplete work

Incomplete work is information about forecasting, refinement, capacity, technical complexity, or external constraints. The appropriate response is inspection, not automatic overtime. The Product Owner reassesses unfinished items in the Product Backlog, while the team examines whether its Definition of Done, slicing strategy, or workflow needs improvement.

Conflict and unequal participation

Healthy disagreement can improve decisions. Destructive conflict, interruption, ridicule, or exclusion reduces learning. A Scrum Master can use round-robin input, silent writing before discussion, explicit decision criteria, and a pause when behavior violates working agreements. Facilitation must also recognize structural power: a junior participant may technically be invited but practically unable to disagree with a senior manager.

Distributed and hybrid teams

Distributed teams need explicit agreements about time zones, response expectations, documentation, meeting access, and decision records. A hybrid meeting in which some participants share a room while others appear on a single laptop often creates unequal participation. Remote-first tools and equal access can reduce this problem.

8. Applied Case: Improving Cadence at Northstar Health

The following is an illustrative case.

Background

Northstar Health is developing a patient appointment platform. It uses two-week Sprints with a Product Owner, six Developers, and a Scrum Master. Stakeholders include clinic administrators, security specialists, customer support, and a compliance officer.

Problem

Sprint Reviews have become slide presentations attended by few stakeholders. Daily Scrums routinely last 35 minutes and focus on individual status reports. The team frequently carries incomplete work into the next Sprint. Retrospectives produce long lists of complaints but few implemented changes. Management has begun comparing the team’s velocity with that of another team.

Analysis

The events are occurring, but their purposes are not being achieved. Planning emphasizes ticket volume rather than a coherent objective. Daily Scrum participation is oriented toward managerial reporting. The Review provides little usable evidence, so stakeholders cannot provide timely feedback. The Retrospective lacks prioritization and follow-through. Velocity comparison creates an incentive to inflate estimates rather than improve value delivery.

Approach

The Scrum Master works with the Product Owner and Developers to introduce the following changes:

1. Planning begins with a Sprint Goal focused on reducing failed appointment confirmations.
2. Developers select fewer, vertically sliced items and include monitoring and security work in the Definition of Done.
3. The Daily Scrum walks the board from items closest to completion and identifies impediments to the Sprint Goal.
4. The Review demonstrates the complete appointment-confirmation flow, including a test with clinic staff and operational evidence.
5. The Retrospective selects one improvement: pair a Developer with customer support for the first hour of each incident investigation.
6. Management stops using velocity to compare teams and instead reviews goal outcomes, quality, and customer evidence.

Outcome

After three Sprints, stakeholders attend the Review more consistently because the demonstrations address real operational questions. The team identifies a third-party messaging failure earlier and adjusts the Product Backlog. Daily Scrum duration falls to approximately 15 minutes because detailed problem-solving moves to focused follow-up conversations. One improvement experiment is completed and evaluated rather than replaced by a long list of intentions.

The team does not achieve perfect predictability. Instead, it improves transparency: incomplete work is visible, Sprint Goals are meaningful, and decisions are made using product evidence. This is a more appropriate measure of Scrum maturity than meeting attendance or velocity growth.

Learning Points

The case illustrates that event quality depends on purpose, evidence, participation, and follow-through. A team can follow the calendar while failing to practice empiricism. Conversely, a concise event can be effective when it enables genuine inspection and adaptation. Facilitation should improve the system without taking ownership away from the Scrum Team.

9. Technology, AI, and Governance Considerations

Digital boards, integrated test pipelines, dashboards, video platforms, and collaborative documents can make work and decisions more transparent. Tools should support the events rather than dictate them. A dashboard that counts completed tickets but excludes defects and unfinished work may create a false picture of progress.

AI tools may assist with summarizing discussions, identifying repeated impediments, drafting acceptance-test ideas, or analyzing large volumes of feedback. Their use requires human verification. Teams should not upload confidential patient, customer, employee, or proprietary data to an unapproved service. AI-generated summaries can omit dissent, misattribute statements, or create an appearance of consensus. A human participant should confirm important decisions and preserve an appropriate decision record.

Governance requirements may affect the cadence. In regulated contexts, evidence of approvals, security testing, accessibility evaluation, data protection, and traceability may be part of the Definition of Done. Governance should be integrated into product work where possible rather than postponed to a release-stage queue. Compliance does not eliminate agility; it changes the evidence that a usable and acceptable Increment must provide.

10. Best-Practice Checklist

Before a Sprint:

• Is the Product Goal understood?
• Is the Product Backlog ordered and sufficiently clear for discussion?
• Are availability, dependencies, risks, and governance constraints visible?
• Can the team formulate a coherent Sprint Goal?

During the Sprint:

• Can Developers inspect progress toward the Sprint Goal?
• Are impediments made visible and acted upon?
• Does the team preserve quality and the Definition of Done?
• Are changes negotiated transparently rather than hidden?

At the Sprint Review:

• Is a usable Increment inspected?
• Are stakeholders engaged in dialogue rather than passive viewing?
• Is feedback connected to future Product Backlog decisions?

At the Retrospective:

• Can participants speak safely and honestly?
• Has the team identified a small number of important improvements?
• Are actions specific, owned, and reviewed in a later Sprint?

Chapter Summary

Scrum events create a repeating cadence for empirical product management. The Sprint is a fixed-length container in which the Scrum Team pursues a coherent Sprint Goal and produces a usable Increment. Sprint Planning establishes the objective, forecast, and initial plan. The Daily Scrum enables Developers to inspect progress and adapt their immediate work. The Sprint Review uses product evidence and stakeholder dialogue to guide future decisions. The Sprint Retrospective examines how the team works and selects practical improvements.

Effective facilitation protects purpose, timeboxes, participation, transparency, and psychological safety. It does not replace the team’s ownership of product and technical decisions. Timeboxes are maximum constraints rather than targets, and capacity or velocity measures must not be mistaken for precise productivity or value. Events are successful when they produce better information, better decisions, and meaningful adaptation—not merely when they occur on schedule.

Key Terms

Scrum Event: A structured activity that supports transparency, inspection, and adaptation.

Sprint: A fixed-length period during which the Scrum Team creates a usable Increment.

Sprint Goal: A single objective that gives the Sprint coherence and guides trade-offs.

Sprint Planning: The event that initiates a Sprint by deciding its value, forecast, and plan.

Daily Scrum: A 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the plan.

Sprint Review: A collaborative event for inspecting the Increment and adapting future Product Backlog direction.

Sprint Retrospective: An event for inspecting teamwork and selecting improvements.

Product Goal: The long-term objective for the Scrum Team’s product.

Product Backlog: An ordered, evolving list of work needed to improve the product.

Sprint Backlog: The Sprint Goal, selected Product Backlog items, and the actionable plan for delivering them.

Increment: A usable, verified addition to the product that meets the Definition of Done.

Definition of Done: The shared quality standard required for work to be considered complete.

Timebox: A maximum duration established for an activity or event.

Empiricism: Decision-making based on transparency, inspection, and adaptation.

Capacity: The estimated availability of a team for planned work, including known constraints.

Forecast: A reasoned expectation of what the team may accomplish, not an unconditional guarantee.

Impediment: An obstacle that restricts progress or reduces the team’s ability to deliver value.

Stakeholder: A person or group with an interest in, knowledge of, or influence on the product.

Psychological Safety: A shared belief that people can raise concerns, questions, and mistakes without fear of humiliation or retaliation.

Backlog Refinement: An ongoing activity that improves the clarity, size, ordering, and readiness of Product Backlog items.

Review Questions

Short Answer Questions

1. What is the main purpose of the Sprint Goal?

1. Why is the Daily Scrum not primarily a status-reporting meeting?

1. State two characteristics of a useful Sprint Review.

1. What does the Definition of Done protect?

1. Why should velocity generally not be used to compare Scrum Teams?

Long Answer Questions

1. Explain how Sprint Planning connects the Product Goal, Sprint Goal, Product Backlog, and Sprint Backlog.

1. Compare the purposes and participation practices of the Daily Scrum and Sprint Retrospective.

1. Describe how a Scrum Master can facilitate a psychologically safe Retrospective.

1. Explain why a Sprint Review should be treated as a working session rather than a product demonstration alone.

1. Discuss the role of timeboxes in Scrum and explain why automatically scaling every timebox can be inappropriate.

Analytical / Application Questions

1. A team completes many tickets but fails to achieve its Sprint Goal because the work was unrelated and several items did not meet the Definition of Done. Diagnose the planning problems and propose corrective actions.

1. During a Daily Scrum, a senior Developer answers every question while other participants remain silent. Design a facilitation response that preserves the event’s purpose and improves participation.

1. A regulated healthcare product team receives an urgent security incident during a Sprint. Explain how the team should make the interruption visible, assess its effect on the Sprint Goal, and adapt its plan without concealing unfinished work.

Multiple Choice Questions with Answers

Question 1

Which event establishes the Sprint Goal, the forecast of work, and the initial plan for completing it?

A. Sprint Planning

B. Daily Scrum

C. Sprint Review

D. Sprint Retrospective

Correct Answer: A. Sprint Planning

Question 2

Who are the primary participants in the Daily Scrum?

A. The Product Owner only

B. The Developers

C. External stakeholders only

D. The organization’s senior managers

Correct Answer: B. The Developers

Question 3

What is the maximum duration commonly associated with the Daily Scrum?

A. 10 minutes

B. 15 minutes

C. 30 minutes

D. 60 minutes

Correct Answer: B. 15 minutes

Question 4

Which statement best describes the Sprint Review?

A. It is a private performance evaluation of Developers.

B. It is a meeting to assign tasks for the next Sprint.

C. It is a collaborative inspection of the Increment and possible future adaptations.

D. It is a technical design approval meeting run by the Scrum Master.

Correct Answer: C. It is a collaborative inspection of the Increment and possible future adaptations.

Question 5

What should happen to work that does not meet the Definition of Done by the end of a Sprint?

A. It is represented as complete if most of it is finished.

B. It is automatically carried over as completed work.

C. It is returned to the Product Backlog for possible future consideration.

D. It is deleted from all records.

Correct Answer: C. It is returned to the Product Backlog for possible future consideration.

Question 6

Which characteristic best describes an effective Sprint Goal?

A. It is a list of every task assigned to each Developer.

B. It is a single objective that gives the Sprint coherence.

C. It is a fixed technical design that cannot change.

D. It is a target for maximizing individual utilization.

Correct Answer: B. It is a single objective that gives the Sprint coherence.

Question 7

A team has three Developers, each with 8 available days, 6 potentially useful hours per day, and an availability factor of 0.75. Using C_available = ∑(D_i × H_i × A_i), what is the estimated capacity?

A. 96 person-hours

B. 108 person-hours

C. 120 person-hours

D. 144 person-hours

Correct Answer: B. 108 person-hours

Question 8

What is the primary purpose of the Sprint Retrospective?

A. To inspect how the team works and identify useful improvements

B. To approve the Product Owner’s budget

C. To demonstrate unfinished work to customers

D. To calculate a universal productivity score

Correct Answer: A. To inspect how the team works and identify useful improvements

Question 9

Which practice is most likely to improve the quality of a Sprint Review?

A. Presenting only slide-based status reports

B. Demonstrating a usable Increment and inviting stakeholder feedback

C. Preventing stakeholders from asking questions

D. Treating all incomplete work as complete

Correct Answer: B. Demonstrating a usable Increment and inviting stakeholder feedback

Question 10

Why is comparing teams by velocity generally discouraged?

A. Velocity cannot be recorded in any tool.

B. Velocity comparison can encourage gaming and does not directly measure value.

C. Velocity is always identical across Sprints.

D. Velocity applies only to the Product Owner.

Correct Answer: B. Velocity comparison can encourage gaming and does not directly measure value.