Return to site

SCRUM: The Definition of "Done" vs Acceptance Criteria by Ralph Jocham

· scrum

There's often a misunderstanding about which is which.

DOD ☑️

First, let's look at the definition of Done.

Let's have a quick look at the scrum guide.

In the scrum guide, it states that the purpose of each sprint is to deliver increments of potentially releasable functionality.

Functionality that adheres to the current scrum team definition of done.

That raise the question: "What exactly is the increment?".

The increment is the sum of all the product backlog items (PBI) completed during a sprint and the value of the increments of all the previous sprints.

It's the whole product and at the end of a sprint, your increment must be done.

That means: it must in usable condition.

So the definition of done is about of current and future viability.

Typical DOD ☝️

Especially as the scrum guide also states as scrum team matures, it is expected that the definition of done will expand to include more stringent criteria for higher quality.👌DOD ☑️

Often typical elements in DOD usually address

📚 the documentation concerns for users, as well as

👨 💼 technical governance,

⚖️ If needed regulatory aspect laws and so on

📐 telemetry (how can you measure user behavior changes after releases),

🔧 technical quality aspects (either provided directly by the organization, if not by the scrum team itself),

🗣️ nonfunctional requirements (often approved by product owner as listed explicitly).Typical DOD ☝️

It is cool especially in the eraly sprints that the DOD is being extended.

In that regard, it is important to have come up with a DOD before going into the very first sprint.

Remember during the Sprint review, you only demo done product functinoality.

Acceptance criteria (AC) ✅

From the scrum guide: "at the end of a sprint, the neew increment must be done which means it must be usable condition.

So what does "usable" mean?

During a sprint, PBI out of the product backlog are turned into the done increment.

Each of those PBI usually represents functionality which needs to be usable.

This usability is enabled by fulfiling the acceptance criteria specific to each of those PBI.

Often these AC are discovered during the produc backlog refinement.

AC are there to guarantee individual FETAURE FITNESS.

AC for PBI usually addressed functionality concerns often also regards to the

🎨 UI acceptance tests

🎬 in the form of scenarios of concrete examples, which we refer to a specification by example,

💾 input/output dataset for specific testing criteria.

AC need to be black⚫ and white⚪, there is no room for interpretation.

Also AC often directly addresses Non Functional Requirements concerns to ensure product doneness.

Summary 🎙️


whereas the AC are about individual FEATURE FITNESS.