Done Criteria

A shared set of completion standards that apply to every user story. A clear, agreed Definition of Done reduces ambiguity and ensures the team meets required quality practices. These standards are established when creating the prioritized product backlog. A user story counts as done only after it is shown to the Product Owner and accepted against the Done Criteria and the story-specific acceptance criteria.

Key Points

  • Common checklist for all user stories that defines minimum completeness and quality.
  • Removes ambiguity, aligns expectations, and reduces rework.
  • Typically covers code, tests, reviews, integration, documentation, and deployability.
  • Used by the Product Owner to accept work; distinct from story-level acceptance criteria.

Example

A Scrum team defines Done Criteria: code peer-reviewed, unit tests at 80% coverage and passing, integrated to main branch, updated user documentation, security checks passed, and acceptance criteria met. At sprint review, the team demos a story; the Product Owner verifies these Done Criteria plus the story's acceptance criteria before accepting it.

PMP Example Question

Which statement best describes Done Criteria in an agile project?

  1. A list of tasks in the sprint backlog for a specific story.
  2. A shared definition of completion that applies to all user stories.
  3. The acceptance criteria written by the Product Owner for one story.
  4. A release plan describing how increments are deployed to production.

Correct Answer: B — A shared definition of completion for all stories

Explanation: Done Criteria are the common standards used to judge whether any user story is complete, while acceptance criteria are specific to a single story.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Eight teaching sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Build an ICS/OT cybersecurity foundation that fits the real environment

Standard IT controls can disrupt the industrial systems they are meant to protect. Learn how to assess OT risk, design zones and conduits, apply IEC 62443 security levels, use MITRE ATT&CK for ICS, and establish passive asset visibility without risking production. Eight reconstructed incidents connect attacker techniques to the controls that failed, giving you the vocabulary and judgment to make credible security decisions from day one.

Explore the Course