SkarpChapter 14 of 21
Artifacts III: Increment, Definition of Done, and Ensuring Quality
Follow work as it becomes a usable Increment that meets the Definition of Done, and see how this commitment protects transparency, quality, and long‑term sustainability.
From Work to Increment: Where Value Becomes Real
Where Work Becomes Value
In previous modules, you saw how ideas become a Product Backlog and then a Sprint Backlog. Now we focus on the moment work becomes real value: the Increment and the Definition of Done.
Canonical Definitions
Increment: "An Increment is a concrete stepping stone toward the Product Goal." Definition of Done: "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product."
Thing vs. Quality Bar
The Increment is the thing you build each Sprint. The Definition of Done is the shared quality bar that tells you when that thing is actually complete and potentially releasable.
Exam Focus
For PSM I, you must recall both definitions exactly, and reason about Done vs. not‑Done, multiple Increments per Sprint, and how the Definition of Done supports transparency and prevents technical debt.
Deep Dive: What Exactly Is an Increment?
Increment: Canonical Definition
The Scrum Guide: "An Increment is a concrete stepping stone toward the Product Goal." Concrete means usable, not just a plan or promise.
Usable and Potentially Releasable
At the end of each Sprint, the sum of Increments must be in a state where it could be released. The Product Owner decides whether to actually release it.
Additive and Integrated
Each Increment builds on all previous Increments. New work is integrated into the existing product, not left as separate prototypes or branches that cannot be shipped.
Meets the Definition of Done
If work does not meet the Definition of Done, it is not part of the Increment. Coded but untested or unintegrated work is progress, but not Incremental value.
Deep Dive: What Exactly Is the Definition of Done?
Definition of Done: Canonical
Scrum Guide: "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product."
Formal and Explicit
It is a visible, agreed list of conditions describing what must be true about the Increment, not a vague or implicit understanding in people’s heads.
Who Defines It?
It may be defined by the organization; if not, the Scrum Team defines it. The team can make it stricter than the organizational standard, but never weaker.
Commitment for the Increment
For the Increment artifact, the commitment is the Definition of Done. The whole Scrum Team is accountable for quality; Developers ensure each Increment meets this Definition.
A Concrete Picture: Sample Definition of Done and Increment
Scenario: Learning Platform
A Scrum Team builds a web learning platform. Product Goal: “Learners can complete and track interactive Scrum courses online.” Sprint Goal: “Enable learners to take timed practice quizzes.”
Sample Definition of Done
DoD includes: acceptance criteria met, code reviewed and merged, tests passing in CI, security checks green, text proofread, deployed to staging, docs and monitoring updated.
Resulting Increment
They deliver quiz UI, timer, and analytics, all integrated and meeting the DoD. This is a concrete stepping stone toward the Product Goal and could be released now.
Not Yet Increment
If a feature is coded but missing tests or docs, it does not meet the Definition of Done and is not part of the Increment. It is just work in progress.
How the Definition of Done Enables Transparency and Prevents Technical Debt
Transparency Through DoD
The Definition of Done creates a shared understanding of “complete.” Stakeholders inspect Increments that truly meet this bar, so feedback is based on real product behavior.
Making Work Visible
If work does not meet the Definition of Done, it is clearly unfinished. This avoids hidden work and lets the team inspect and adapt based on reality.
Technical Debt Control
By baking in tests, refactoring, and security checks, a strong DoD reduces accidental technical debt and makes any intentional shortcuts visible and trackable.
Exam Trap: Lowering the Bar
Scrum does not recommend weakening the DoD to go faster. Instead, reduce scope while keeping the DoD, so each Increment stays high‑quality and sustainable.
Multiple Increments Per Sprint and Handling Partial Work
Multiple Increments Per Sprint
Each time work meets the Definition of Done, you have an Increment. Developers can create multiple Increments in a Sprint; each is integrated and potentially releasable.
Releasing During the Sprint
Because each Increment is potentially releasable, the Product Owner may release multiple times per Sprint when value is ready and the Definition of Done is met.
What About Partial Work?
If work does not meet the Definition of Done by Sprint end, it is not part of the Increment. It goes back to the Product Backlog to be re‑ordered and completed later.
Exam Patterns to Watch
80% complete still means not Done. Multiple items Done mid‑Sprint mean multiple Increments and possible releases. Minimum is one usable Increment per Sprint; no maximum.
Thought Exercise: Is It Done or Not?
Work through these scenarios and decide whether the work is Done (part of the Increment) or Not Done (still just progress). Answer in your head or jot notes; then compare to the explanations.
- Scenario A
- Team’s Definition of Done includes: code review, automated tests, security scan, updated documentation, and deployment to test environment.
- A new login feature is coded, reviewed, and passes tests, but the security scan is failing due to a library vulnerability.
- Question: Is this feature part of the Increment?
- Answer: Not Done. It does not meet the Definition of Done because the security scan is failing. It cannot be counted as part of the Increment.
- Scenario B
- Definition of Done includes all of the above.
- A reporting feature is fully Done according to the Definition of Done by day 4 of a 2‑week Sprint.
- Question: Has an Increment been created?
- Answer: Yes. The feature meets the Definition of Done and is integrated. It is a concrete stepping stone toward the Product Goal. The Product Owner may choose to release it immediately.
- Scenario C
- Definition of Done includes: code merged, tests passing, documentation updated.
- A bug fix is implemented and merged with tests, but the documentation update is intentionally postponed to next Sprint to “save time”.
- Question: How should the Scrum Team treat this?
- Answer: It is Not Done. Skipping a Definition of Done item to go faster reduces transparency and creates hidden work. The proper choice is to either finish documentation now or treat the bug fix as unfinished and return it to the Product Backlog.
Use these scenarios to train your instinct: if any Definition of Done criterion is missing, it is not Done.
Quiz 1: Core Definitions and Responsibilities
Check your understanding of the Increment and Definition of Done.
Which statement best reflects Scrum’s view of the Definition of Done?
- It is a checklist created by the Scrum Master that Developers should follow when they have time.
- It is a formal description of the state of the Increment when it meets the quality measures required for the product, and it may be defined by the organization or the Scrum Team.
- It is a flexible guideline that Product Owners can change each Sprint to speed up delivery.
- It is a list of acceptance criteria for each Product Backlog item, written by stakeholders.
Show Answer
Answer: B) It is a formal description of the state of the Increment when it meets the quality measures required for the product, and it may be defined by the organization or the Scrum Team.
The canonical definition is: "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product." It can be defined by the organization or, if none exists, by the Scrum Team. It is not optional, not owned solely by the Scrum Master or Product Owner, and it is broader than item‑specific acceptance criteria.
Quiz 2: Multiple Increments and Partial Work
Apply what you know to exam‑style scenarios.
At the end of a Sprint, one Product Backlog item is 90% complete but does not meet the Definition of Done. What is the BEST action according to Scrum?
- Count 90% of the item as part of the Increment so stakeholders can see progress.
- Include the unfinished item in the Increment but clearly label it as beta.
- Do not include the item in the Increment; return it to the Product Backlog for re‑ordering.
- Extend the Sprint by a few days so the team can finish the item and include it in the Increment.
Show Answer
Answer: C) Do not include the item in the Increment; return it to the Product Backlog for re‑ordering.
Work that does not meet the Definition of Done is not part of the Increment. It returns to the Product Backlog and can be re‑ordered by the Product Owner. Sprints are never extended to finish work, and partially Done items are not counted as part of the Increment, even if labeled beta.
Key Term Flashcards: Increment and Definition of Done
Flip these cards mentally or aloud to reinforce exact wording and key ideas.
- Increment (canonical definition)
- An Increment is a concrete stepping stone toward the Product Goal.
- Definition of Done (canonical definition)
- The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
- Who may define the Definition of Done?
- It may be defined by the organization. If the organization does not have one, the Scrum Team must define a Definition of Done that is appropriate for the product. The team can make it more stringent than the organizational standard, but not weaker.
- Commitment for the Increment artifact
- For the Increment artifact, the commitment is the Definition of Done. The Scrum Team commits to ensuring each Increment meets this Definition.
- Usable / potentially releasable Increment
- An Increment is usable when it meets the Definition of Done and is integrated so it could be released. The Product Owner decides whether to actually release it.
- Handling unfinished work at Sprint end
- If work does not meet the Definition of Done, it is not part of the Increment. It returns to the Product Backlog for re‑ordering; Sprints are not extended to finish it.
- Multiple Increments per Sprint
- Every time work meets the Definition of Done and is integrated, an Increment is created. A Scrum Team can create multiple Increments within a Sprint, and the Product Owner may release them at any time.
- Definition of Done vs. acceptance criteria
- Acceptance criteria describe when a specific Product Backlog item meets stakeholder expectations. The Definition of Done is a broader, product‑wide quality bar that applies to every Increment.
Apply It: Improving a Weak Definition of Done
Imagine you join a new Scrum Team. Their current Definition of Done is:
- Code compiles
- Feature demo works on the developer’s machine
- Identify problems
- What risks do you see with this Definition of Done?
- How could this impact transparency and technical debt over the next 6–12 months?
Pause and think before reading on.
- Typical risks
- Lack of testing: Bugs will surface late, often in production.
- No integration requirement: Features might work on one machine but fail when combined.
- No documentation or monitoring: Harder to operate, support, or extend the product.
- Low transparency: Stakeholders see “demos” that look fine, but hidden quality issues accumulate.
- Strengthening the Definition of Done
- Propose 3–5 additions that would make this Definition of Done more robust while still realistic for a student‑level product team.
- Example improvements:
- Automated unit tests written and passing.
- Code merged into main branch and built on CI.
- Basic regression tests executed on an integrated environment.
- User‑visible changes documented (e.g., change log or help text).
- Exam connection
- If you see an exam question where a team wants to “skip tests this Sprint” or “relax the Definition of Done to deliver more items”, ask: What happens to transparency and technical debt?
- The Scrum‑consistent answer is to keep the Definition of Done, reduce scope if needed, and inspect/adapt at the Sprint Retrospective.
Bringing It Together: Increment, DoD, and Your Exam Strategy
Lock In the Definitions
Increment: "An Increment is a concrete stepping stone toward the Product Goal." Definition of Done: "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product."
Done vs. Not Done
If work does not meet the Definition of Done, it is not part of the Increment. Partial items go back to the Product Backlog; closeness does not matter.
Commitment and Multiple Increments
The commitment for the Increment is the Definition of Done. Teams can create multiple Increments per Sprint, and the Product Owner may release whenever value is ready.
Quality and Your Study Path
A strong DoD protects transparency and limits technical debt. In your Skarp path, mock exams and diagnostics will stress‑test these ideas until they are automatic.
Key Terms
- Sprint
- Sprints are the heartbeat of Scrum, where ideas are turned into value.
- Increment
- An Increment is a concrete stepping stone toward the Product Goal.
- Developers
- Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
- Product Goal
- The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
- Transparency
- A core Scrum pillar meaning that significant aspects of the process and product must be visible to those responsible for the outcome, based on a common standard of what is being seen.
- Technical debt
- The extra work and risk created when a team chooses a quicker, lower‑quality solution now instead of a cleaner, more sustainable one; it accumulates and slows future delivery if unmanaged.
- Definition of Done
- The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
- Potentially releasable
- A state in which an Increment meets the Definition of Done and is integrated so that it could be released to users, even if the Product Owner decides not to release it yet.