Scrum has three artifacts. Each one answers a fundamental question about the work: What do we want to build? What are we building right now? What have we already built?
Understanding these artifacts isn't just theoretical — as a QA engineer, you'll interact with all three of them every single day.
Learning Objectives
By the end of this lesson you will be able to:
- Define the Product Backlog, Sprint Backlog, and Increment
- Explain the concept of "Definition of Done" and why it matters for quality
- Describe the relationship between the three artifacts
- Explain why an untested feature cannot be part of a valid Increment
Artifact 1: The Product Backlog
The Product Backlog is the single source of truth for all work on the product. Think of it as an ordered to-do list for the entire product.
Key properties:
- Owned by the Product Owner — only the PO can officially re-order or add/remove items
- Always evolving — new items are added, old items are refined or deleted as understanding grows
- Ordered, not prioritized — "ordered" is a more precise word; item #1 is more important than item #2, full stop
- Refined over time — the act of making backlog items ready for a sprint (adding detail, estimates, acceptance criteria) is called backlog refinement
Items on the Product Backlog are usually written as User Stories: "As a [user], I want [goal] so that [reason]." Each story should have acceptance criteria that define when it's done.
For QA: The acceptance criteria on backlog items are your testing contract. If a feature meets all its acceptance criteria and nothing unexpected broke, the story is potentially done. Reading the backlog — especially upcoming items — gives you advance notice to plan test approaches before the sprint starts.
Artifact 2: The Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the current sprint, plus a plan for delivering them.
Key properties:
- Owned by the Developers (including QA)
- Created during Sprint Planning — the team selects items and breaks them into tasks
- Updated daily — as work is done, the sprint backlog reflects what's left
- Fixed scope during the sprint — items should not be added or removed once the sprint starts (with rare exceptions)
The Sprint Backlog is your team's contract with itself: "This is what we committed to, and this is how we're going to do it."
For QA: This is where you create test tasks, track which stories have been verified, and flag when a story's testing is blocked. If a story has no QA task in the Sprint Backlog, it probably won't get tested in this sprint.
Artifact 3: The Increment
The Increment is the sum of all completed Product Backlog items from the current sprint plus all previous sprints. It is the concrete, working, usable version of the product at any given moment.
The critical word: "Done." An Increment must meet the team's Definition of Done (DoD) — a shared, explicit standard of what "complete" means. If an item doesn't meet the DoD, it is not part of the Increment.
The Definition of Done: Quality's Guardian
The Definition of Done is the most important quality tool in Scrum, and it's almost never used as well as it should be.
A typical, healthy DoD might include:
- All acceptance criteria passed
- Unit tests written and passing
- Code reviewed by at least one peer
- Tested by QA (manual or automated)
- No critical or major bugs open
- Documentation updated (if applicable)
- Deployed to staging environment
Why this matters: Without a shared DoD, "done" becomes a matter of opinion. A developer says "done" when the code compiles. A QA says "done" when tests pass. A PO says "done" when the feature works in production. The DoD aligns all three.
The golden rule: An untested feature is NOT an Increment. If QA hasn't verified the story within the sprint, it goes back to the Product Backlog, not into the Increment. This is uncomfortable but critical — shipping untested code and calling it "done" is how technical debt accumulates.
How the Three Artifacts Connect
Product Backlog (all work)
↓ [Sprint Planning selects items]
Sprint Backlog (this sprint's work)
↓ [Team builds, QA tests, DoD verified]
Increment (working, done software)
↓ [Shown at Sprint Review, informs next sprint]
Product Backlog (updated with feedback)
This cycle repeats every sprint — which is why Scrum is described as empirical: each sprint generates new evidence (working software + stakeholder feedback) that informs the next plan.
Pro Tips
If your team's Definition of Done doesn't include "tested by QA," your Increment is aspirational, not actual. Push for a DoD that includes explicit QA sign-off.
Backlog items without acceptance criteria are bugs waiting to happen. As a QA engineer, you have standing to ask "What does done look like for this story?" during refinement sessions. That question prevents entire classes of misunderstandings.
Summary
- The Product Backlog is the ordered list of all work on the product — owned by the PO, always evolving.
- The Sprint Backlog is the current sprint's selected work plus the team's plan — owned by the Developers.
- The Increment is the sum of all completed, DoD-verified work — the living product.
- The Definition of Done is the quality contract that defines what "complete" means for the team.
- An untested feature does not meet the DoD and is not a valid Increment — testing is part of "done," not after it.