Overview
Scrum Artifacts is the seventh SMPC learning-objective area. The 2020 Scrum Guide says artifacts represent work or value and are designed to maximize transparency of key information, so everyone inspecting them has the same basis for adaptation. There are three: the Product Backlog, the Sprint Backlog and the Increment. Each contains a commitment that provides a focus against which progress can be measured. The Product Goal belongs to the Product Backlog, the Sprint Goal to the Sprint Backlog, and the Definition of Done to the Increment.
The area also covers Product Backlog refinement, the ongoing act of breaking down items and adding detail such as description, order and size, and the rule that work cannot be considered part of an Increment unless it meets the Definition of Done. Expect questions that pair artifacts with commitments, owners and events, and scenarios about undone work or unclear quality standards.
How it's tested
Most questions in this area are matching or rule-based: which commitment belongs to which artifact, who can change the Sprint Backlog, what happens to undone work, or who creates the Definition of Done. Scenario items test whether you protect transparency and quality when pressure mounts near the end of a Sprint.
-
Artifact and commitment pairing
You match the Product Backlog, Sprint Backlog and Increment with the Product Goal, Sprint Goal and Definition of Done.
-
Undone work
An item fails to meet the Definition of Done near the end of the Sprint, and you decide what happens to it.
-
Ownership and change
Someone wants to edit an artifact, and you decide who may change it and when.
On the last day of a Sprint, an item works but has not been tested as the Definition of Done requires. The Product Owner wants to show it at the Sprint Review as finished. The tempting answer is to present it with a caveat. The Guide says an item that does not meet the Definition of Done cannot be released or even presented at the Sprint Review; it returns to the Product Backlog for future consideration.
Topics 3
Official topics from the CertiProf outline, in outline order.
7.1 Product Backlog and the Product GoalThe ordered list of what is needed to improve the product, with its long-term commitment.
- What it means
- The Product Backlog is an emergent, ordered list of what is needed to improve the product and the single source of work undertaken by the Scrum Team. Its commitment is the Product Goal, which describes a future state of the product and serves as a target for planning.
- What to understand
- Items that can be done within one Sprint are deemed ready for selection at Sprint Planning; they usually reach this state through refinement. Refinement breaks items into smaller, more precise ones and adds details such as description, order and size. The Developers who will do the work are responsible for sizing, and the Product Owner may influence them by helping them understand trade-offs. The Product Goal is in the Product Backlog, and the team must fulfil or abandon one objective before taking on the next.
- How it shows up
- Expect questions on the Product Goal, refinement responsibility and the single-source rule.
- Common confusion
- Confusing the Product Goal with the Sprint Goal, or thinking the Product Owner sizes items.
7.2 Sprint Backlog and the Sprint GoalThe Developers' plan for the Sprint, with its single objective.
- What it means
- The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). It is a plan by and for the Developers.
- What to understand
- The Sprint Backlog is highly visible, real-time and updated throughout the Sprint as more is learned. Its commitment, the Sprint Goal, is the single objective for the Sprint; it is created at Sprint Planning and added to the Sprint Backlog. The Sprint Goal gives flexibility in the exact work needed to achieve it. If the work turns out differently than expected, Developers collaborate with the Product Owner to negotiate the scope of the Sprint Backlog without affecting the Sprint Goal.
- How it shows up
- Scenarios ask who can change the Sprint Backlog and what happens when scope must change mid-Sprint.
- Common confusion
- Thinking the Sprint Backlog is fixed after Sprint Planning or owned by the Product Owner.
7.3 Increment and the Definition of DoneUsable steps toward the Product Goal and the quality standard they must meet.
- What it means
- An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified so they work together. Its commitment is the Definition of Done, a formal description of the state of the Increment when it meets the quality measures required for the product.
- What to understand
- Work becomes part of an Increment only when it meets the Definition of Done. Multiple Increments may be created within a Sprint, and an Increment may be delivered to stakeholders before the Sprint ends; the Sprint Review should never be treated as a gate to releasing value. If the Definition of Done is part of organizational standards, all Scrum Teams must follow it as a minimum; otherwise the Scrum Team creates one. Teams working on the same product share one Definition of Done.
- How it shows up
- Questions test who creates the Definition of Done, release timing and what happens to undone work.
- Common confusion
- Believing the Scrum Master writes the Definition of Done or that Increments can only be released at the end of a Sprint.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Three artifacts
Product Backlog, Sprint Backlog and Increment.
- Remember
- Each has one commitment.
- Tested as
- Recall items.
- Trap
- Adding a burndown chart as an artifact.
-
Product Goal
A future state of the product; target for planning.
- Remember
- Commitment for the Product Backlog.
- Tested as
- 2020 pairing questions.
- Trap
- Calling it a Sprint-level objective.
-
Sprint Goal
Single objective for the Sprint.
- Remember
- Commitment for the Sprint Backlog.
- Tested as
- Scope negotiation questions.
- Trap
- Changing it to fit new work.
-
Definition of Done
Formal quality description for the Increment.
- Remember
- Commitment for the Increment.
- Tested as
- Undone-work scenarios.
- Trap
- Pairing it with the Sprint Backlog.
-
Single source of work
The Product Backlog holds all work for the team.
- Remember
- No side lists.
- Tested as
- Work-intake scenarios.
- Trap
- Accepting work outside the backlog.
-
Refinement
Ongoing breakdown and detailing of backlog items.
- Remember
- Developers size; the Product Owner orders.
- Tested as
- Responsibility questions.
- Trap
- Treating it as a timeboxed event.
-
Sprint Backlog ownership
A plan by and for the Developers.
- Remember
- Updated throughout the Sprint.
- Tested as
- Who-changes-it items.
- Trap
- Letting managers edit it.
-
Undone work
Items not meeting the Definition of Done.
- Remember
- Not released or presented; returned to the Product Backlog.
- Tested as
- End-of-Sprint scenarios.
- Trap
- Showing it as partially done.
-
Multiple Increments
Several may be created and delivered within a Sprint.
- Remember
- The Review is not a release gate.
- Tested as
- Release-timing questions.
- Trap
- Waiting for the Review to release.
-
Shared Definition of Done
Teams on one product use the same one.
- Remember
- Organizational standards are a minimum.
- Tested as
- Multi-team questions.
- Trap
- Each team writing its own standard.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Artifacts, commitments and owners
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Product Backlog | Ordered list of what improves the product | Commitment: Product Goal; managed by the Product Owner | Thinking stakeholders edit it directly |
| Sprint Backlog | Sprint Goal, selected items and plan | Commitment: Sprint Goal; owned by Developers | Treating it as fixed after planning |
| Increment | Verified, usable step toward the Product Goal | Commitment: Definition of Done; whole team | Counting undone work as part of it |
Product Goal vs. Sprint Goal
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Product Goal | Long-term objective for the product | Fulfilled or abandoned before the next one | Rewriting it every Sprint |
| Sprint Goal | Single objective for one Sprint | Created at Sprint Planning; scope may flex around it | Swapping it mid-Sprint for new work |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Present undone work
- What candidates pick
- Showing an untested item at the Sprint Review as nearly finished.
- Why it looks right
- Stakeholders want to see progress.
- Why it's wrong
- Work that does not meet the Definition of Done cannot be released or presented at the Sprint Review.
Clue to watch for Words like almost done or pending testing.
-
Wrong commitment pairing
- What candidates pick
- Definition of Done for the Sprint Backlog.
- Why it looks right
- Both relate to the Sprint.
- Why it's wrong
- The Definition of Done is the Increment's commitment; the Sprint Goal belongs to the Sprint Backlog.
Clue to watch for Any matching question on commitments.
-
Release only at the Review
- What candidates pick
- Holding a finished Increment until the Sprint Review.
- Why it looks right
- The Review inspects the outcome.
- Why it's wrong
- The Guide says Increments can be delivered before the Sprint ends and the Review is not a release gate.
Clue to watch for A stakeholder needing value mid-Sprint.
-
Product Owner sizes items
- What candidates pick
- The Product Owner estimates backlog items.
- Why it looks right
- They know the requirements best.
- Why it's wrong
- The Developers who will do the work are responsible for sizing; the Product Owner helps them understand trade-offs.
Clue to watch for Questions about estimation responsibility.
-
Each team its own Done
- What candidates pick
- Separate Definitions of Done for teams on one product.
- Why it looks right
- Teams have different skills.
- Why it's wrong
- Multiple Scrum Teams on the same product must share one Definition of Done for an integrated Increment.
Clue to watch for Several teams building one product.
Answer framework
Apply these steps to questions about artifacts, commitments, ownership and quality standards.
- Identify the artifact in the question and state its commitment: Product Goal, Sprint Goal or Definition of Done, without mixing them up.
- Decide who manages or owns it: the Product Owner for the Product Backlog, the Developers for the Sprint Backlog, the whole team for the Increment.
- For quality or completion questions, test the work against the Definition of Done; anything that fails returns to the Product Backlog.
- For scope changes, protect the Sprint Goal and let Developers renegotiate Sprint Backlog scope with the Product Owner as they learn.
- For release timing, remember that Increments can be delivered whenever they are done, so the Sprint Review is not an approval gate.
Practice question
Want more like this? The SMPC practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
The Scrum Artifacts section of the 2020 Scrum Guide is short, so read it several times rather than relying on summaries. Make a three-row table with columns for artifact, commitment, owner, when it is created or updated, and the event that inspects it. Memorize the commitment pairs first, because they are the most directly tested facts.
Next, focus on the Definition of Done. Write out the rules: work only becomes part of an Increment when it meets it, undone items return to the Product Backlog, organizational standards are a minimum, and teams on one product share one definition. Then add the release rule that Increments may be delivered before the end of the Sprint.
Finally, practise end-of-Sprint scenarios where pressure tempts the team to bend quality or present undone work, and scope-change scenarios where the Sprint Goal must be protected. Link each answer back to transparency, since artifacts exist to make the true state of the work visible.
FAQ
What portion of the SMPC exam covers Scrum Artifacts?
CertiProf does not publish a share for Scrum Artifacts or any SMPC area. The section is short but rule-heavy; this guide plans for about five of the 40 questions.
What are the three commitments?
The Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog and the Definition of Done for the Increment.
Who creates the Definition of Done?
If the organization has a standard, all Scrum Teams follow it as a minimum. Otherwise the Scrum Team creates a Definition of Done appropriate for the product.
Can an Increment be released before the Sprint Review?
Yes. The Guide says Increments may be delivered to stakeholders before the end of the Sprint. The Review is not a release gate.
Who can change the Sprint Backlog?
The Developers, who own it. They renegotiate scope with the Product Owner when needed while protecting the Sprint Goal.
Is a burndown chart a Scrum artifact?
No. Burndown charts are optional practices. Scrum's artifacts are the Product Backlog, Sprint Backlog and Increment.
Other Agile & Scrum certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 7 knowledge
Check your grasp of artifacts, commitments and the Definition of Done with a short SMPC practice set before tackling full mock exams.