Scrum is an empirical framework for developing, delivering, and sustaining complex products. Its effectiveness depends not only on events and accountabilities but also on the quality of its artifacts. Scrum artifacts make important work visible, while their associated commitments provide shared reference points for inspection and adaptation.
The three Scrum artifacts are:
Product Backlog—an ordered, evolving list of everything needed to improve the product.
Sprint Backlog—the Sprint Goal, selected Product Backlog items, and an actionable plan for delivering the Increment.
Increment—a concrete, usable step toward the Product Goal.
Each artifact has a corresponding commitment:
Artifact
Commitment
Main purpose
Product Backlog
Product Goal
Describes the future state toward which the Scrum Team works
Sprint Backlog
Sprint Goal
Provides the objective for the current Sprint
Increment
Definition of Done
Establishes the quality standard required for completed work
Together, these artifacts create a chain of alignment: the Product Goal gives strategic direction, the Sprint Goal focuses near-term delivery, and the Definition of Done protects product quality.
Learning Objectives
By the end of this chapter, learners should be able to:
explain the purpose and structure of the Product Backlog;
describe how the Product Goal guides Product Backlog management;
construct and manage a Sprint Backlog;
formulate a useful Sprint Goal;
explain what constitutes an Increment;
apply a Definition of Done consistently;
distinguish transparency, inspection, and adaptation in artifact management;
identify common risks, governance issues, and practical improvement strategies.
Scrum Artifacts as Instruments of Empirical Control
Scrum is based on empiricism: knowledge comes from experience and decisions are made on the basis of what is observed. Empirical process control rests on three pillars:
Transparency: important aspects of the process must be visible to those responsible for outcomes.
Inspection: artifacts and progress toward goals are examined frequently enough to detect undesirable variation.
Adaptation: the process or work is adjusted when inspection reveals that it is outside acceptable limits or no longer appropriate.
Artifacts support these pillars. A Product Backlog that hides technical debt is not transparent. A Sprint Backlog that is never reviewed cannot support inspection. An Increment that is demonstrated but not tested cannot support trustworthy adaptation.
Artifacts are not merely documents. They are shared information structures used by the Scrum Team and stakeholders. A backlog may be represented in a digital product-management system, a physical board, or another suitable medium. The medium is less important than the accuracy, accessibility, and usefulness of the information.
The Product Backlog
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. Product Backlog items may include customer capabilities, defects, research, compliance work, infrastructure, security improvements, and technical debt reduction.
The Product Owner is accountable for effective Product Backlog management. This includes:
developing and explicitly communicating the Product Goal;
creating and clearly communicating Product Backlog items;
ordering Product Backlog items;
ensuring that the Product Backlog is transparent, visible, and understood.
The Product Owner may delegate some work, but accountability remains with the Product Owner. Product Backlog management is not isolated from the Scrum Team. Developers contribute technical knowledge, and stakeholders provide information about users, markets, risks, and organizational constraints.
Ordering rather than a simple list
Ordering expresses relative priority and sequencing. It is not limited to commercial value. A Product Owner may consider:
expected customer value;
risk reduction;
regulatory deadlines;
dependencies;
technical feasibility;
learning value;
cost of delay;
operational resilience;
accessibility and inclusion.
A high-value feature may not be the next item if a smaller technical capability is necessary to make it feasible or safe. Ordering is therefore a product decision informed by evidence, not merely a ranking produced by one stakeholder.
Product Backlog refinement
Refinement is the activity of breaking down and further defining Product Backlog items. It is continuous and does not constitute a formal Scrum event. During refinement, the Scrum Team may clarify user needs, identify assumptions, split large items, explore technical options, and estimate relative size.
A useful Product Backlog item normally communicates:
the desired outcome or capability;
the users or beneficiaries affected;
relevant acceptance conditions;
dependencies and constraints;
evidence or assumptions requiring validation.
The Product Backlog is never finished. As the product, market, technology, and understanding change, the backlog changes. This is a strength of Scrum, provided change remains connected to the Product Goal.
Estimation and uncertainty
Scrum does not prescribe a particular estimation technique. Teams may use relative sizing, affinity grouping, historical evidence, or other approaches. Estimates are forecasts, not contractual promises. They express uncertainty about effort, complexity, and knowledge.
For example, a team might classify items as small, medium, and large. Such labels have meaning only within that team and product context. A “large” item in one product cannot automatically be compared with a “large” item in another.
A backlog becomes unhealthy when items are vague, enormous, duplicated, technically disconnected, or ordered without a clear rationale. Refinement should increase shared understanding without turning the backlog into a detailed long-range specification that assumes the future is predictable.
The Product Goal
The Product Goal is the commitment for the Product Backlog. It describes a future state of the product and serves as a target toward which the Scrum Team plans. The team works toward one Product Goal at a time.
A useful Product Goal is:
outcome-oriented rather than merely activity-oriented;
understandable to both delivery specialists and stakeholders;
sufficiently stable to guide multiple Sprints;
measurable or assessable through evidence;
connected to a genuine product need.
For example, “build five reporting screens” describes output. “Enable small-business customers to understand monthly cash flow without external assistance” describes a more meaningful product state. The second statement can guide decisions about usability, data quality, accessibility, and support—not just screen production.
The Product Goal does not eliminate uncertainty or guarantee commercial success. It provides direction for learning and prioritization. If evidence shows that the goal is no longer desirable or feasible, the Product Owner and relevant stakeholders may revise product direction. Such revision should be explicit rather than concealed through constant uncoordinated backlog changes.
The Sprint Backlog
The Sprint Backlog is a plan by and for the Developers. It consists of:
the Sprint Goal;
the set of Product Backlog items selected for the Sprint;
an actionable plan for delivering the Increment.
The Sprint Backlog is a real-time picture of the work that Developers plan to accomplish during the Sprint. It should be sufficiently detailed for the team to inspect progress and adapt its plan. It is not a fixed contract or a task list imposed by external management.
Developers update the Sprint Backlog throughout the Sprint as more is learned. The plan may become more detailed as work proceeds. If the work is different from what was expected, Developers collaborate with the Product Owner to negotiate scope while preserving the Sprint Goal whenever possible.
The Sprint Goal
The Sprint Goal is the commitment for the Sprint Backlog. It is the single objective of the Sprint. It creates coherence and focus, allowing flexibility in the exact work required to achieve it.
A strong Sprint Goal usually:
expresses a valuable outcome or learning objective;
links selected items into a meaningful purpose;
helps Developers make trade-offs;
supports stakeholder understanding;
remains stable during the Sprint unless the Sprint is cancelled.
Weak goal: “Complete items 12, 13, and 14.”
Stronger goal: “Allow trial users to complete account registration and receive confirmation securely.”
The stronger goal provides decision guidance. If one selected item becomes unnecessary, the team can assess whether the goal can still be achieved. If an unforeseen technical task is essential to secure registration, it may be added to the plan because it supports the goal.
The Product Owner proposes how the Sprint could create value, while Developers determine what can be done and how the work will be accomplished. Sprint Planning establishes the Sprint Goal, selected work, and initial plan.
The Increment
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to previous Increments and must be thoroughly verified, ensuring that all Increments work together. Multiple Increments may be created within a single Sprint. They may be delivered to stakeholders before the Sprint Review; the Sprint Review is not a release gate.
For work to be part of the Increment, it must meet the Definition of Done. Work that does not meet the Definition of Done is not considered part of the Increment and should not be presented as complete. It may be returned to the Product Backlog for future consideration.
An Increment must be usable. “Usable” does not necessarily mean publicly released, but it means the product state could be used or released if the Product Owner chose to do so. Release decisions may depend on market timing, legal review, deployment strategy, or other organizational considerations. However, release postponement must not be used to hide incomplete quality.
The Increment provides evidence. Stakeholders can inspect actual product behavior rather than relying solely on status reports or plans. This makes feedback more reliable and enables adaptation of the Product Backlog and Product Goal.
The Definition of Done
The Definition of Done is the commitment for the Increment. It is a formal description of the state of the Increment when it meets the quality measures required for the product.
If a Product Backlog item does not meet the Definition of Done, it is not complete. The Definition of Done creates a shared quality threshold and prevents different people from using the word “done” to mean different things.
A Definition of Done might include:
code reviewed by another qualified team member;
automated tests passing;
required exploratory testing completed;
security and privacy checks completed where relevant;
accessibility criteria satisfied;
documentation updated;
data migration verified;
monitoring and rollback arrangements prepared;
acceptance criteria satisfied;
deployment or release readiness demonstrated.
The exact contents depend on the product and organizational context. A medical system, payment service, educational application, and internal prototype will have different risks and controls.
The Definition of Done must be realistic but demanding. If it is so weak that defects are routinely carried forward, it fails as a quality commitment. If it is impossible to satisfy with available capability, the team may be encouraged to misrepresent progress. The Scrum Team should improve the Definition of Done as its quality capability increases.
An organizational standard may provide a minimum Definition of Done. Teams may add stricter product-specific criteria, but they should not silently reduce the required standard. When multiple Scrum Teams work on one product, they should share and follow the same Definition of Done unless an explicitly governed product arrangement states otherwise.
Relationships among the Commitments
The three commitments operate at different horizons:
The Product Goal answers: “What product state are we trying to achieve?”
The Sprint Goal answers: “What valuable objective will we pursue now?”
The Definition of Done answers: “What quality conditions must be true before this work counts as complete?”
These commitments should reinforce one another. A Sprint Goal disconnected from the Product Goal creates local activity without strategic progress. A Sprint Goal pursued without a strong Definition of Done produces apparent progress without reliable value. A Definition of Done without meaningful goals can result in technically polished work that solves the wrong problem.
Relationship between Scrum artifacts and their commitments
Figure: Relationship between Scrum artifacts and their commitments
Figure: Scrum artifacts and commitments form a connected empirical system.
Managing Artifacts in Practice
A practical artifact-management routine can include the following activities:
Clarify the Product Goal. Confirm the intended product outcome and the evidence that would indicate progress.
Maintain the Product Backlog. Add, remove, split, reorder, and clarify items as knowledge changes.
Refine upcoming work. Ensure that likely Sprint candidates are understandable and sufficiently prepared without attempting to specify everything in advance.
Formulate the Sprint Goal. State the purpose of the Sprint before finalizing the selected work.
Create the Sprint plan. Developers identify an achievable selection and an actionable approach.
Inspect daily. Developers compare current evidence with the Sprint Goal and adapt their plan.
Verify against the Definition of Done. Quality is assessed continuously, not at the last hour of the Sprint.
Use the Increment for feedback. Stakeholders and the Scrum Team inspect what actually exists.
Adapt future work. Feedback changes Product Backlog ordering, item content, or possibly the Product Goal.
Example of backlog adaptation
Suppose an online learning product has a Product Goal to help adult learners complete short professional courses. The initial backlog contains video playback, downloadable transcripts, progress tracking, and discussion forums. Early testing shows that learners abandon lessons when they lose their place on mobile devices. The Product Owner may reorder resume-playback and mobile progress synchronization above discussion forums. This is not failure of planning; it is evidence-based adaptation.
Applied Case: Northstar Benefits Portal
The following is an illustrative case created for educational purposes.
Background
Northstar, a mid-sized employer, is developing a benefits portal. Employees currently use paper forms and separate web pages to select health and retirement options. The Scrum Team includes a Product Owner, five Developers, and a Scrum Master. The organization has a security policy requiring authentication controls, audit logging, and documented testing.
Problem
The first two Sprints produced attractive screens, but stakeholders discovered that eligibility rules were incomplete and that no audit trail existed. The team had reported the screens as “done,” although they could not safely be used.
Analysis
The Product Backlog contained technical tasks and interface requests but no explicit Product Goal. Sprint Goals were lists of activities, such as “complete the dashboard.” The team had no shared Definition of Done. As a result, visual completion was confused with a usable Increment.
Approach
The team established the Product Goal: “Enable eligible employees to select benefits securely and receive a reliable confirmation of their choices.”
The Definition of Done was revised to require:
implemented acceptance conditions;
automated unit and integration tests;
eligibility-rule verification using representative test data;
accessibility checks;
security review of authentication and authorization;
audit logging of benefit selections;
updated user and support documentation;
deployment to a test environment with demonstrated rollback capability.
For the next Sprint, the team created the Sprint Goal: “Allow an eligible employee to review available options and save a secure selection with confirmation.” The selected Product Backlog items included eligibility display, selection storage, confirmation messaging, and audit logging. Developers created a plan that included test data and security verification rather than treating them as optional final tasks.
Outcome
The resulting Increment contained fewer visible screens than the previous Sprint, but it supported a complete, testable employee journey. During the Sprint Review, stakeholders discovered that one category of dependent eligibility required an additional rule. The Product Owner added and ordered a follow-up backlog item. The team did not claim that the incomplete rule was part of the Increment.
Learning points
A Product Goal connects individual features to a product outcome.
A Sprint Goal creates flexibility while preserving focus.
The Definition of Done prevents cosmetic progress from being reported as usable value.
Quality work must be planned as part of delivery, not postponed until the end.
Feedback from an Increment improves future backlog decisions.
Common Failure Modes and Their Remedies
Treating the Product Backlog as a contract
A fixed backlog can discourage learning and make evidence appear to be a threat. The remedy is to treat the backlog as an evolving product strategy while maintaining clear accountability for outcomes.
Using the Sprint Backlog as a management assignment sheet
When work is assigned externally, Developers lose ownership of the plan and may conceal emerging problems. Developers should create and adapt their own plan in collaboration with the Product Owner.
Writing activity-based goals
“Complete ten tasks” does not explain value or guide trade-offs. Reframe the goal around a user, business, operational, or learning outcome.
Redefining “done” during the Sprint
Changing quality expectations to make unfinished work appear complete destroys transparency. If the Definition of Done needs improvement, change it explicitly and apply the appropriate standard consistently.
Measuring progress by item count alone
Counting completed items can reward small, low-value work and hide unresolved risk. Complement item information with evidence of usable outcomes, quality, customer response, and progress toward the Product Goal. No single metric proves product success.
Confusing release with completion
An Increment can be usable without being released. Conversely, releasing work that does not meet the Definition of Done is a quality and governance failure, not an example of agility.
Governance, Ethics, and Risk
Artifact management has ethical and governance implications. Inaccurate status reporting can cause financial loss, unsafe releases, regulatory breaches, or harm to users. Teams should make uncertainty visible rather than presenting forecasts as guarantees.
Relevant controls may include:
traceability from regulatory or safety needs to Product Backlog items;
privacy-by-design and data-minimization practices;
accessibility criteria within the Definition of Done;
security testing and vulnerability management;
audit evidence for critical changes;
separation of duties where required by regulation;
protection of confidential backlog information;
explicit handling of technical debt and known defects.
Artificial intelligence tools may assist with backlog summarization, duplicate detection, acceptance-test suggestions, or analysis of feedback. However, generated content can be incomplete, biased, insecure, or factually wrong. A Product Owner and Developers remain accountable for ordering, technical decisions, privacy, and quality. AI-generated backlog items must be reviewed by people with relevant product and domain knowledge.
Contemporary Developments
Modern product organizations increasingly manage multiple teams, continuous delivery pipelines, remote collaboration, and rapidly changing regulatory environments. These conditions make artifact transparency more important, not less. Digital boards can provide useful history and automated evidence, but tool configuration should not replace conversation or judgment.
In continuous delivery environments, several Increments may be produced during a Sprint, and deployment may occur many times per day. The essential requirement remains unchanged: each Increment must meet the Definition of Done. In product-led organizations, outcome evidence—such as user success, reliability, accessibility, and business impact—should complement delivery evidence.
Best Practices Checklist
A Scrum Team can periodically ask:
Is the Product Goal clear and still relevant?
Can stakeholders understand why the top backlog items are ordered as they are?
Are upcoming items sufficiently understood without excessive specification?
Does the Sprint Goal express a coherent objective?
Can Developers explain how the Sprint Backlog supports that objective?
Is the Sprint Backlog updated as new information appears?
Is the Increment genuinely usable?
Is the Definition of Done visible, objective, and consistently applied?
Are quality, security, accessibility, and compliance included where relevant?
Does feedback from the Increment change future decisions?
Chapter Summary
Scrum artifacts make product work visible and support empirical control. The Product Backlog is an ordered and emergent source of work, managed under the accountability of the Product Owner. Its commitment, the Product Goal, describes the future product state toward which the Scrum Team works.
The Sprint Backlog contains the Sprint Goal, selected Product Backlog items, and an actionable plan created and adapted by Developers. Its commitment, the Sprint Goal, focuses the Sprint on a coherent objective while allowing flexibility in the detailed plan.
The Increment is a usable, additive step toward the Product Goal. It must satisfy the Definition of Done, which is the commitment for the Increment and the shared quality standard for completed work. The three commitments connect strategic direction, near-term focus, and product quality.
Effective artifact management requires transparency, frequent inspection, and timely adaptation. It also requires responsible governance: teams must represent progress honestly, protect users, address security and accessibility, and avoid using tools or metrics as substitutes for professional judgment.
Key Terms
Product Backlog: An ordered, evolving list of everything needed to improve the product.
Product Goal: The commitment describing a future state of the product.
Product Backlog item: A discrete piece of product work, such as a capability, defect, research task, or technical improvement.
Ordering: Establishing the relative sequence of Product Backlog items.
Refinement: The ongoing activity of adding detail, estimates, and clarity to Product Backlog items.
Sprint Backlog: The Sprint Goal, selected Product Backlog items, and the plan for delivering the Increment.
Sprint Goal: The commitment and single objective for a Sprint.
Increment: A concrete, usable, additive step toward the Product Goal.
Definition of Done: A formal description of the quality state required for an Increment to count as complete.
Transparency: Making important aspects of work and progress visible and understandable.
Inspection: Examining artifacts and progress to detect problems or change.
Adaptation: Adjusting work or process in response to inspection.
Empiricism: Decision-making based on observation and experience.
Usable: In a state that can be used or released if appropriate, even if release is postponed.
Technical debt: The future cost created by choosing an expedient technical solution over a more effective one.
Acceptance condition: A condition that helps establish whether a Product Backlog item satisfies its intended need.
Product Owner: The Scrum accountability responsible for maximizing product value and effective Product Backlog management.
Developers: The Scrum Team members who create the usable Increment.
Review Questions
Short Answer Questions
What are the three Scrum artifacts?
What is the commitment associated with the Product Backlog?
Why must an Increment satisfy the Definition of Done?
Who creates and adapts the Sprint Backlog?
What is the purpose of a Sprint Goal?
Long Answer Questions
Explain how transparency, inspection, and adaptation operate through Scrum artifacts.
Discuss the responsibilities involved in effective Product Backlog management.
Compare the Product Goal and Sprint Goal, including how they guide decisions at different time horizons.
Explain the role of the Definition of Done in quality assurance, governance, and stakeholder trust.
Describe how a Scrum Team should manage changing information during a Sprint without losing focus.
Analytical / Application Questions
A team reports six interface screens as complete, but security testing, accessibility checks, and integration testing have not been performed. Analyze whether these screens form part of the Increment and recommend an appropriate response.
A Product Owner orders a customer-facing feature above a regulatory compliance task because the feature has greater expected revenue. Using Scrum artifact and commitment principles, evaluate this decision and propose questions that should inform the ordering.
A Sprint contains many unrelated technical tasks and has no shared objective. Construct a suitable Sprint Goal and explain how the Sprint Backlog and Definition of Done should be revised to support it.
Multiple Choice Questions with Answers
Question 1
Which commitment is associated with the Product Backlog?
A. Definition of Done
B. Product Goal
C. Sprint Goal
D. Release plan
Correct Answer: B. Product Goal
Question 2
Who is accountable for effective Product Backlog management?
A. The Scrum Master alone
B. The stakeholders collectively
C. The Product Owner
D. The Developers alone
Correct Answer: C. The Product Owner
Question 3
What does the Sprint Backlog contain?
A. Only Product Backlog estimates
B. The Sprint Goal, selected items, and an actionable plan
C. Only tasks assigned by the Product Owner
D. All future product requirements
Correct Answer: B. The Sprint Goal, selected items, and an actionable plan
Question 4
Which statement best describes the Sprint Goal?
A. A list of every task in the organization
B. A fixed contractual scope statement
C. The single objective for the Sprint
D. A quality checklist for released software
Correct Answer: C. The single objective for the Sprint
Question 5
When is work part of an Increment?
A. When it has been discussed in refinement
B. When a developer says it is nearly complete
C. When it meets the Definition of Done
D. When it appears on the Sprint Backlog
Correct Answer: C. When it meets the Definition of Done
Question 6
Which activity is continuous and is not a formal Scrum event?
A. Product Backlog refinement
B. Sprint Review
C. Daily Scrum
D. Sprint Retrospective
Correct Answer: A. Product Backlog refinement
Question 7
A team discovers during a Sprint that one selected item is unnecessary, but the Sprint Goal remains achievable. What is the most appropriate response?
A. Continue the unnecessary work because Sprint scope cannot change
B. Collaborate with the Product Owner and adapt the plan or scope
C. Cancel the Sprint automatically
D. Change the Definition of Done to include the item
Correct Answer: B. Collaborate with the Product Owner and adapt the plan or scope
Question 8
Which statement about an Increment is correct?
A. Only one Increment may be created per Sprint
B. An Increment must always be released immediately
C. An Increment must be usable and meet the Definition of Done
D. An Increment may contain work that fails required quality criteria
Correct Answer: C. An Increment must be usable and meet the Definition of Done
Question 9
What is the primary purpose of a Definition of Done?
A. To assign tasks to individual Developers
B. To establish the quality state required for completed work
C. To determine the commercial price of a product
D. To replace Product Backlog ordering
Correct Answer: B. To establish the quality state required for completed work
Question 10
Which example is the strongest Sprint Goal?
A. Complete tasks 1, 2, and 3
B. Work on the database
C. Allow trial users to register and receive secure confirmation
D. Produce ten development estimates
Correct Answer: C. Allow trial users to register and receive secure confirmation