Scrum Events, Artifacts and Commitments

Introduction and context

Scrum is a lightweight framework for developing and sustaining complex products. It does not prescribe a complete product-development process, a particular technology, or a fixed project-management methodology. Instead, it establishes a small set of accountabilities, events, artifacts, and rules that enable empiricism: decisions are based on observation and experience rather than on predictions alone.

Empiricism rests on three pillars. Transparency means that important aspects of the work are visible and understood in a common way. Inspection means that Scrum participants frequently examine artifacts and progress toward goals. Adaptation means that the process or product direction is adjusted when inspection reveals unacceptable variation or new information. Scrum events provide regular opportunities for this inspection and adaptation; Scrum artifacts provide visible representations of value, work, and product quality; and commitments give each artifact a clear purpose and reference point.

For product managers, Scrum is especially important because it connects strategic intent with short learning cycles. The Product Goal expresses the product’s longer-term objective. The Product Backlog translates that objective into an evolving, ordered set of work. The Sprint Goal provides a near-term outcome for a Sprint, while the Definition of Done establishes the quality threshold for the Increment. Effective product leadership requires more than attending meetings: it requires creating clarity, making trade-offs explicit, enabling evidence-based decisions, and protecting the integrity of the product and its users.

Learning objectives

After studying this chapter, the learner should be able to:

1. Explain the purpose and time-boxes of the Sprint and its constituent events.
2. Prepare and facilitate effective Sprint Planning, Daily Scrums, Sprint Reviews, and Sprint Retrospectives.
3. Distinguish the Product Backlog, Sprint Backlog, and Increment.
4. Explain the relationship among the Product Goal, Sprint Goal, and Definition of Done.
5. Apply inspection and adaptation to realistic product-development situations.
6. Evaluate common Scrum failure modes, including status-oriented events, excessive commitment, weak quality controls, and stakeholder disengagement.

1. Scrum as an empirical operating system

A Scrum Team consists of one Product Owner, one Scrum Master, and Developers. The team has no sub-teams or hierarchies and is cross-functional: collectively, it possesses the skills needed to create value each Sprint. The Product Owner is accountable for maximizing product value and for effective Product Backlog management. The Scrum Master is accountable for establishing Scrum as defined and improving the Scrum Team’s effectiveness. Developers are accountable for creating a usable Increment each Sprint.

A Sprint is a fixed-length event of one month or less in which ideas are turned into value. A new Sprint starts immediately after the previous one ends. Sprints provide cadence and limit the period during which uncertainty can accumulate. During a Sprint, changes that would endanger the Sprint Goal are avoided, quality does not decrease, the Product Backlog is refined as needed, and scope may be clarified and renegotiated with the Product Owner as more is learned.

The Sprint contains Sprint Planning, Daily Scrums, the work of development, the Sprint Review, and the Sprint Retrospective. These are not independent administrative meetings. Together, they form a learning loop: establish a goal, plan a valuable slice, inspect progress frequently, inspect the resulting product with stakeholders, and improve the way of working.

Time-boxes

For a one-month Sprint, the maximum time-boxes are:

For shorter Sprints, the events are usually shorter. These are maximum durations, not targets that must be filled. The Sprint Review and Retrospective occur near the end of the Sprint, while the Daily Scrum occurs each working day, preferably at a consistent time. The Scrum Master helps ensure that events occur and remain purposeful, but the Scrum Team is responsible for the content and outcome of its work.

2. Sprint Planning: creating a coherent near-term strategy

Sprint Planning initiates the Sprint by establishing three related elements: the reason the Sprint is valuable, the work that can be undertaken, and the plan for delivering that work. Its output is the Sprint Backlog, consisting of the Sprint Goal, selected Product Backlog items, and an actionable plan for delivering the Increment.

Sprint Planning addresses three questions.

Why is this Sprint valuable?

The Product Owner proposes how the product could increase its value and utility during the Sprint. The entire Scrum Team then collaborates to define a Sprint Goal. The Sprint Goal is the single objective for the Sprint. It creates flexibility: the team may renegotiate the exact scope with the Product Owner as it learns more, provided the Sprint Goal is not endangered.

A weak Sprint Goal is merely a list, such as “complete items A, B, C, and D.” A stronger goal describes an outcome or coherent capability, such as “enable new customers to activate a trial account without contacting support.” The latter helps the team make trade-offs when capacity, technical uncertainty, or new evidence changes the plan.

What can be done this Sprint?

Developers select Product Backlog items for inclusion based on the Product Goal, their understanding of the current Product Backlog, their capacity, and their historical delivery experience. Selection is a forecast, not a guarantee. The Product Owner helps participants understand the items and their value; Developers make the technical judgment about what can realistically be accomplished.

Selection should consider dependencies, operational work, quality activities, discovery, technical risk, and interruptions. Treating only visible feature work as capacity ignores the actual conditions under which a product is built. The team should also ensure that selected items are sufficiently understood to begin, while recognizing that complete certainty is neither possible nor necessary.

How will the chosen work get done?

Developers plan the work necessary to create an Increment that meets the Definition of Done. They may decompose Product Backlog items into smaller tasks, identify design or testing activities, and make dependencies visible. The plan should be detailed enough to support coordination and adaptation, not so detailed that it becomes a rigid contract.

A useful Sprint Backlog makes the relationship among the Sprint Goal, selected items, and delivery approach visible. It is updated throughout the Sprint as more is learned. A plan that is never changed is often evidence that inspection is superficial rather than evidence of exceptional certainty.

Product management implications

The Product Owner should arrive with an ordered, transparent, and sufficiently refined Product Backlog, but refinement is an ongoing activity rather than a formal Scrum event. Product Backlog items may include customer-facing functionality, technical improvements, defects, compliance work, research, and other work needed to improve the product. The Product Owner remains accountable for ordering, even when other people contribute information or perform the work of refinement.

3. The Daily Scrum: coordinating toward the Sprint Goal

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. It is not primarily a reporting meeting for a manager, Product Owner, or Scrum Master.

Developers may use any structure that produces the required outcome. A common format asks:

• What progress has been made toward the Sprint Goal?
• What is the most important work or risk for the next day?
• What impediments or dependencies require action?

The familiar three-question format—what I did yesterday, what I will do today, and what is blocking me—is permitted but not required. It can become ineffective when each person speaks to a supervisor rather than when the team coordinates around a shared goal.

The Daily Scrum is most valuable when work is integrated and inspected rather than when individual activity is recited. Developers may continue detailed conversations after the 15-minute event. They should update the Sprint Backlog, swarm on urgent work, expose emerging risks, and seek help early. A remote team can use a shared visual board, explicit working agreements, and asynchronous evidence before the event, while preserving real-time discussion for decisions and coordination.

4. The Sprint Review: inspecting the product and adapting direction

The Sprint Review is a working session, not a ceremonial presentation. Its purpose is to inspect the outcome of the Sprint with key stakeholders and determine future adaptations. The Scrum Team presents relevant results, discusses progress toward the Product Goal, and invites evidence about market conditions, customer needs, technology, operations, regulation, and competitive change.

The Product Owner discusses what has been accomplished and what has changed in the Product Backlog. Developers explain the work, demonstrate the usable Increment, and answer questions. Stakeholders provide feedback and may help identify the most valuable next steps. The group collaborates on what to do next, which may result in changes to Product Backlog ordering, content, or the Product Goal.

A meaningful review demonstrates working product behavior rather than relying on slides or claims of completion. Feedback should be connected to decisions. If stakeholders attend only to approve completed work, the organization loses the opportunity to reduce uncertainty. Likewise, a review should not become a sales performance in which inconvenient evidence is hidden.

The Increment is inspected against the Definition of Done. Items that do not meet that definition cannot be presented as part of the Increment, although they may remain in the Product Backlog. The Product Owner may decide to release value before the Sprint ends; the Sprint Review is not a release approval gate. Release decisions depend on product strategy, risk, customer need, and organizational policy.

5. The Sprint Retrospective: improving the system of work

The Sprint Retrospective is the final formal event of the Sprint. The Scrum Team inspects how the last Sprint went with respect to individuals, interactions, processes, tools, and its Definition of Done. It identifies the most useful changes and addresses the most influential causes of problems. Improvements may be added to the Sprint Backlog for the next Sprint or otherwise acted upon.

A psychologically safe Retrospective distinguishes learning from blame. The team can examine questions such as:

• Which practices helped us move toward the Sprint Goal?
• Where did waiting, rework, or misunderstanding occur?
• What evidence suggests that quality or flow is deteriorating?
• Which one or two changes are sufficiently important to try next?

A Retrospective that produces ten vague actions usually produces none. Effective actions are specific, owned by the team rather than assigned as punishment, and observable. For example, “improve testing” is weak; “pair a Developer and tester on acceptance examples before implementation for the next Sprint” is more actionable. The Scrum Master supports facilitation and removes barriers but does not turn the event into an external audit.

6. The three Scrum artifacts and their commitments

Scrum artifacts are designed to maximize transparency of key information. Each artifact has a commitment that provides a reference point against which progress and quality can be inspected.

6.1 Product Backlog and Product Goal

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Items become clearer and smaller through refinement. Ordering considers value, risk, learning, dependencies, urgency, and effort; no universal ranking formula replaces product judgment.

The Product Goal describes a future state of the product and serves as the long-term objective for the Scrum Team. The team should fulfill, abandon, or replace one Product Goal before taking on the next. A Product Goal is not a detailed roadmap or a fixed list of features. It gives meaning to backlog ordering and helps distinguish valuable adaptation from random scope churn.

Transparency requires that Product Backlog items have a shared understanding of their purpose, acceptance expectations, and relationship to the Product Goal. Relative estimation techniques may support conversation, but estimates are not commitments and should not be used as precise promises. The Product Owner must make ordering visible and explain trade-offs, while stakeholders and Developers supply relevant evidence.

6.2 Sprint Backlog and Sprint Goal

The Sprint Backlog is a plan by and for Developers. It includes the Sprint Goal, selected Product Backlog items, and the actionable plan. Developers update it throughout the Sprint. It should reveal current understanding, not preserve the appearance of the original plan.

The Sprint Goal is the commitment for the Sprint Backlog. It provides coherence and focus while allowing the exact work to adapt. If a selected item becomes unnecessary for the goal, the team can remove or replace it through discussion with the Product Owner. If the goal becomes obsolete, only the Product Owner can cancel the Sprint. Cancellation is uncommon and should reflect a genuinely invalid objective, not ordinary difficulty.

6.3 Increment and Definition of Done

An Increment is a concrete stepping stone toward the Product Goal. It must be usable and must meet the Definition of Done. Multiple Increments may be created during a Sprint, and their value may be delivered before the Sprint Review. Work does not become an Increment merely because it is coded, merged, demonstrated, or marked “90 percent complete.”

The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the product. If an organizational standard exists, every Scrum Team must follow it as a minimum. If no standard exists, the Scrum Team creates a DoD appropriate to the product. It may include code review, automated and exploratory testing, security checks, accessibility verification, documentation, monitoring, data migration, and deployment readiness.

The DoD is not the same as acceptance criteria. Acceptance criteria describe conditions for a particular Product Backlog item; the DoD applies to all work included in the Increment. An item that fails the DoD cannot be released or presented as part of the Increment. It returns to the Product Backlog for future consideration, although the Product Owner may choose its eventual priority.

A strong DoD protects users and the organization from hidden quality debt. It also makes progress honest: “done” has a stable meaning even when scope changes.

7. Connecting the commitments across horizons

The three commitments form a hierarchy of intent:

• The Product Goal gives strategic and product-level direction.
• The Sprint Goal translates that direction into a near-term outcome.
• The Definition of Done protects the quality of every Increment used to pursue the outcome.

For example, suppose a financial-services product has the Product Goal: “Enable small-business customers to obtain a reliable cash-flow view.” A Sprint Goal might be: “Allow a customer to connect one bank account and view categorized transactions.” The Definition of Done might require integrated code, privacy and security checks, reconciliation tests, accessibility testing, monitoring, and updated support content. The Sprint Goal explains why the selected work matters; the DoD explains what quality means.

This relationship prevents two common distortions. First, a team can deliver technically complete features that do not advance a meaningful product objective. Second, a team can pursue an attractive goal while releasing fragile or unsafe functionality. Product value and product quality must be managed together.

8. Applying empiricism through useful measures

Scrum does not mandate a specific metric system. Measures are useful only when they improve understanding and decisions. Product managers should distinguish outcome measures from output measures.

Outcome measures may include task completion rate, successful customer activation, retention, error reduction, or user-reported task success. Output measures include completed backlog items, story points, or lines of code. Outputs can help describe activity but do not prove value.

A team may inspect cycle time, escaped defects, deployment frequency, support contacts, or Sprint Goal achievement. These measures should be interpreted in context. For example, velocity is a local planning aid, not a productivity score or a valid basis for comparing teams. Increasing points can indicate changed estimation, item splitting, or gaming rather than increased customer value.

Forecasting should communicate uncertainty. If a team historically completes a variable number of comparable items, a range is more honest than a single date. Trends can inform planning, but past performance is not a guarantee because product work is affected by dependencies, discovery, technical change, and team composition. Metrics must not incentivize concealment, cutting quality, or optimizing local activity at the expense of the product system.

9. Detailed applied case: CarePath appointment platform

Background

CarePath is an illustrative telehealth platform used by regional clinics. Patients currently request appointments by telephone. The product team has a Product Goal: “Enable patients to find and book an appropriate available appointment without staff intervention.” The team includes a Product Owner, Scrum Master, five Developers, a clinical-domain specialist, and access to security and accessibility expertise.

Problem

During refinement, the team discovers that “online booking” could mean several things: searching by specialty, validating insurance, selecting a time, collecting symptoms, confirming consent, and sending reminders. A previous team released a booking form that worked technically but produced double bookings and was unusable with keyboard navigation. Stakeholders now disagree about whether speed of release or completeness of the booking journey matters more.

Analysis

The Product Owner orders a thin but valuable slice: patients should be able to search one specialty, view genuinely available slots, and request a booking confirmation. Insurance validation and advanced reminders are deferred. Developers identify risks in calendar synchronization, privacy, accessibility, and concurrent booking. The Scrum Master helps the team expose these risks rather than allowing them to remain implicit.

Sprint Planning

The team defines the Sprint Goal: “Enable a patient to find and request one available appointment for dermatology.” Selected items include availability synchronization, search and filtering, appointment request, confirmation messaging, and essential accessibility and security work. Developers create a plan that includes test data, concurrency tests, audit logging, and review with clinic staff.

The Definition of Done requires peer-reviewed code, automated tests for core rules, tested calendar integration, keyboard and screen-reader accessibility checks, privacy review, monitoring for failed requests, updated support guidance, and deployment to a production-like environment. This prevents the team from treating a visually complete form as a finished Increment.

Daily Scrum and adaptation

Midway through the Sprint, Developers discover that the external calendar occasionally returns stale availability. The team inspects the risk against the Sprint Goal. It removes a low-value filtering enhancement, adds a short-lived reservation mechanism, and asks the Product Owner to clarify the acceptable user message when a slot is no longer available. The Sprint Backlog changes, but the Sprint Goal remains intact.

Sprint Review

Clinic staff and a patient advocate inspect the working Increment. They identify that “request submitted” is ambiguous and that patients need a clear next step. Evidence also shows that staff require an audit trail. The Product Owner reorders the Product Backlog to address confirmation clarity and audit visibility before adding more specialties. The team does not claim that the whole booking product is complete.

Sprint Retrospective

The team finds that security review began too late and that calendar assumptions were not tested against realistic data. It chooses two improvements: involve the security specialist during refinement for integration-related items, and maintain a shared set of time-zone and concurrency test cases. These actions are added to the next Sprint’s working plan.

Outcome and learning points

CarePath has not delivered the entire product, but it has produced a usable, inspected Increment and reduced important uncertainty. The case demonstrates that Sprint Planning is not a promise to complete a fixed feature list, Daily Scrum is not status reporting, Sprint Review is not merely a demonstration, and the Definition of Done is a governance mechanism for quality and risk.

10. Common failure modes and corrective practice

Sprint Planning as a negotiation of capacity versus scope. When leaders impose a feature list, Developers may conceal uncertainty or sacrifice quality. Corrective practice is to establish a valuable Sprint Goal and let Developers make a forecast.

Daily Scrum as individual reporting. This obscures dependencies and encourages local optimization. Recenter discussion on progress toward the Sprint Goal and adapt the plan.

Sprint Review as approval. Stakeholders who only approve completed work provide little learning. Invite them to inspect the product and market evidence and to help shape what happens next.

Retrospective without follow-through. Repeatedly naming the same issue without experimentation damages trust. Select a small number of owned, observable improvements and inspect their effects.

Inflated or unstable Definition of Done. A DoD that is aspirational but routinely ignored is not transparent. A DoD that is too weak transfers risk to users. Establish a credible minimum, improve it progressively, and make exceptions visible rather than silently redefining “done.”

Product Backlog as a requirements warehouse. A long, unexamined list does not constitute strategy. Link ordering to the Product Goal, evidence, risk, and intended outcomes; remove obsolete items.

Technical debt hidden by partial completion. Carrying unfinished work indefinitely creates misleading progress. Make incomplete work visible, preserve the DoD, and allow quality work to influence ordering and capacity.

11. Governance, ethics, and contemporary practice

Scrum teams operate within legal, regulatory, security, and ethical constraints. In healthcare, finance, education, and public services, privacy, accessibility, safety, records management, and explainability may need explicit representation in the Definition of Done and Product Backlog. Compliance cannot be postponed merely because it is inconvenient for a Sprint Goal.

AI-assisted coding, test generation, backlog analysis, and summarization can support Scrum, but they do not transfer accountability. Generated code may contain security defects, licensing problems, bias, or undocumented assumptions. Teams should review outputs, protect confidential data, preserve traceability where required, and test user-facing behavior. An AI system should not be treated as a stakeholder or decision-maker; product accountability remains with the people and organization.

Distributed teams require deliberate transparency. A shared backlog, visible Sprint Goal, accessible decision records, overlapping collaboration hours, and clear escalation paths can preserve empiricism. Tools are not substitutes for shared understanding: a perfectly configured board can still conceal risk if participants do not update it honestly.

Best-practice checklist

Before a Sprint, confirm that the Product Goal is understood, the Product Backlog is ordered and sufficiently refined, and the Product Owner can explain value and trade-offs. During Planning, create one coherent Sprint Goal and a credible Developer-owned forecast. During the Sprint, inspect progress against the goal, adapt the Sprint Backlog, and protect the Definition of Done. At the Review, demonstrate a usable Increment and convert stakeholder evidence into decisions. At the Retrospective, select practical improvements and verify that they are implemented. Across all events, prefer transparency over optimism and learning over ritual compliance.

Chapter Summary

Scrum uses a repeating Sprint cycle to create value under conditions of uncertainty. Sprint Planning establishes why the Sprint matters, what can be achieved, and how the work may be delivered. The Daily Scrum enables Developers to inspect progress toward the Sprint Goal and adapt their plan. The Sprint Review brings the Scrum Team and stakeholders together to inspect the usable Increment and adapt future product direction. The Sprint Retrospective improves the team’s processes, interactions, tools, and quality practices.

The Product Backlog is an evolving, ordered account of work directed toward the Product Goal. The Sprint Backlog contains the Sprint Goal, selected work, and an adaptable delivery plan. The Increment is a usable step toward the Product Goal and must meet the Definition of Done. These commitments connect strategy, near-term focus, and quality. Effective Scrum is therefore not a sequence of status meetings or a mechanism for making fixed promises; it is an empirical system for creating transparency, learning from evidence, and adapting responsibly.

Key Terms

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

Product Goal: The long-term objective describing a future state of the product.

Sprint: A fixed-length event of one month or less in which a usable Increment is created.

Sprint Goal: The single objective and commitment for a Sprint.

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

Increment: A usable, integrated step toward the Product Goal.

Definition of Done: The formal quality description that an Increment must satisfy.

Sprint Planning: The event that establishes the Sprint Goal, forecast, and delivery plan.

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

Sprint Review: An event for inspecting the outcome with stakeholders and adapting future direction.

Sprint Retrospective: An event for inspecting and improving the team’s way of working.

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

Transparency: Visibility and shared understanding of important work and quality information.

Inspection: Frequent examination of artifacts and progress to detect undesirable variation.

Adaptation: Adjustment of the product or process in response to inspection and learning.

Product Owner: The accountability for maximizing product value and managing the Product Backlog effectively.

Developers: Scrum Team members accountable for creating a usable Increment each Sprint.

Scrum Master: The accountability for establishing Scrum and improving Scrum Team effectiveness.

Backlog refinement: The ongoing activity of adding detail, order, and size to Product Backlog items.

Stakeholder: A person or group that affects, is affected by, or provides evidence about the product.

Review Questions

Short Answer Questions

1. What are the three pillars of empiricism in Scrum?
2. What are the three questions addressed by Sprint Planning?
3. Why is the Daily Scrum not primarily a reporting meeting?
4. Distinguish the Sprint Goal from the Definition of Done.
5. What makes an Increment usable?

Long Answer Questions

1. Explain how the Product Goal, Sprint Goal, and Definition of Done connect strategic intent, near-term delivery, and product quality.
2. Describe how a Product Owner should prepare for and contribute to Sprint Planning and the Sprint Review.
3. Compare the purposes of the Sprint Review and Sprint Retrospective. Why should they not be combined?
4. Discuss why estimates, velocity, and other metrics must be interpreted cautiously in Scrum.
5. Explain how the Definition of Done functions as a quality and governance mechanism in a regulated product.

Analytical / Application Questions

1. A team completes all selected backlog items but discovers that the core customer problem remains unsolved. Diagnose the likely weaknesses in its Product Goal, Sprint Goal, and Sprint Review practices.
2. During a Sprint, an external dependency makes one selected item impossible, but the Sprint Goal remains valuable. What should the Product Owner and Developers do, and why?
3. A team repeatedly carries unfinished work into the next Sprint and reports high velocity. Design an evidence-based intervention using the Definition of Done, backlog transparency, and Retrospective improvements.

Multiple Choice Questions with Answers

Question 1

Which commitment provides the long-term objective for the Product Backlog?

A. Sprint Goal

B. Product Goal

C. Definition of Done

D. Release plan

Correct Answer: B. Product Goal

Question 2

Who is accountable for creating the Sprint Backlog plan and deciding what can realistically be accomplished?

A. The Developers

B. The stakeholders

C. The Scrum Master alone

D. The finance function

Correct Answer: A. The Developers

Question 3

What is the primary purpose of the Daily Scrum?

A. To approve releases

B. To estimate the entire Product Backlog

C. To inspect progress toward the Sprint Goal and adapt the plan

D. To evaluate individual employee performance

Correct Answer: C. To inspect progress toward the Sprint Goal and adapt the plan

Question 4

Which statement about the Definition of Done is correct?

A. It applies only to the highest-priority backlog item

B. It is optional when a Sprint Review is scheduled

C. It describes the quality state required for an Increment

D. It is identical to acceptance criteria for every item

Correct Answer: C. It describes the quality state required for an Increment

Question 5

A Sprint Goal remains valid, but one selected Product Backlog item is no longer useful. What is the most appropriate response?

A. Keep the item unchanged to protect the original plan

B. Adapt the Sprint Backlog through discussion with the Product Owner

C. Cancel every Sprint immediately

D. Declare the item done without meeting the Definition of Done

Correct Answer: B. Adapt the Sprint Backlog through discussion with the Product Owner

Question 6

What is the central purpose of the Sprint Review?

A. To inspect the outcome with stakeholders and adapt future direction

B. To assign individual performance ratings

C. To create the Definition of Done from scratch every Sprint

D. To prevent any changes to the Product Backlog

Correct Answer: A. To inspect the outcome with stakeholders and adapt future direction

Question 7

Which item is part of the Sprint Backlog?

A. Only tasks assigned by the Product Owner

B. The Sprint Goal, selected Product Backlog items, and the delivery plan

C. Every possible future product requirement

D. Only work that has already been released

Correct Answer: B. The Sprint Goal, selected Product Backlog items, and the delivery plan

Question 8

A team demonstrates a feature that fails its agreed security and testing requirements. How should it be treated?

A. As part of the Increment because it was demonstrated

B. As an Increment if stakeholders approve it informally

C. As not Done and therefore not part of the Increment

D. As automatically released at the Sprint Review

Correct Answer: C. As not Done and therefore not part of the Increment

Question 9

Which practice best supports an effective Sprint Retrospective?

A. Selecting a small number of specific, observable improvements

B. Assigning blame for every defect to one person

C. Avoiding discussion of process problems

D. Replacing all team agreements every Sprint

Correct Answer: A. Selecting a small number of specific, observable improvements

Question 10

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

A. Velocity is a legal compliance measure

B. Velocity is a local planning measure affected by team context and estimation practices

C. Velocity always measures customer value directly

D. Velocity is fixed by the Scrum Guide

Correct Answer: B. Velocity is a local planning measure affected by team context and estimation practices