Multiple Levels of Done

Multiple Levels of Done

A Definition of Done helps a Scrum team agree on what it means for work to be truly complete.

That sounds simple. But without a shared Definition of Done, “done” can mean very different things to different people.

• To a developer, done might mean the code works on their machine.
• To a tester, done might mean the feature has passed the agreed tests.
• To a product owner, done might mean the feature is usable by customers.
• To a stakeholder, done might mean the feature is documented, supported, and ready to release.

The Definition of Done removes that ambiguity. It gives the Scrum team and its stakeholders a shared understanding of what must be true before work can be considered part of the product Increment.

A typical Definition of Done might include statements like:

• The code is checked in.
• The code is readable and maintainable.
• The work has been reviewed by another team member.
• Automated tests have been added or updated at the appropriate levels.
• The feature has passed the team’s agreed tests.
• User-facing documentation has been updated where needed.
• The work is integrated with the rest of the product.
• The product owner has accepted that the item meets the intent of the backlog item.

Many teams improve their Definition of Done over time. A team may not be able to automate every useful test when it first starts using Scrum, for example. But over time, the team can strengthen its Definition of Done as its skills, tools, and engineering practices improve.

For most Scrum teams, one Definition of Done is exactly right. But there are situations where a team may benefit from multiple levels of done. That idea can be useful. It can also be dangerous.

So let’s be clear from the start: multiple levels of done should never be used as an excuse to split analysis, coding, testing, integration, or documentation across separate sprints.

“Done” must still mean done.

The question is not, “Can we call something done even though important work remains?”

The question is, “What level of completeness is appropriate for the decision we need to make right now?”

One Definition of Done Is Usually Enough

Most Scrum teams should use a single Definition of Done.

A single Definition of Done creates transparency. Everyone knows what it means when the team says a product backlog item is done. The product owner can make better release decisions. Stakeholders can inspect real progress. The team can avoid the hidden pileup of partially finished work that makes forecasting unreliable.

When a team has one Definition of Done, Sprint Planning is clearer. The Daily Scrum is more useful. The Sprint Review is more honest. The team can inspect a real Increment rather than a collection of mostly finished pieces.

This is why I would not encourage most teams to create multiple definitions of done.

If a team says, “Development done, testing done, documentation done, deployment done,” that is usually not multiple levels of done. That is a waterfall process hiding inside Scrum terminology.

And it creates all the old problems.

Work waits for another specialist. Defects are discovered late. The team carries unfinished work from sprint to sprint. The Sprint Review becomes less meaningful because the work being shown is not truly complete.

A better answer is usually to strengthen the team’s Definition of Done and help the team finish smaller pieces of work within a sprint.

When Multiple Levels of Done Can Help

Multiple levels of done can be useful when each level supports a real product decision.

This is most common in domains where teams need to learn whether something is worth continuing before investing in full production quality.

Examples include:

• Game development
• Hardware development
• Embedded systems
• Scientific or technical exploration
• New product discovery
• Complex user experience experiments
• Products with expensive certification, manufacturing, regulatory, or release steps

In these situations, it may be wasteful to take every idea all the way to final-release quality before learning whether the idea is worth pursuing.

The key is that each level of done must still be complete for its purpose.

A prototype done enough to answer a product question is not the same as a sloppy feature. It has to be built, tested, integrated, and reviewed enough that the team and product owner can trust the feedback they receive from it.

An Example from a Game Studio

Game studios understand that not every idea should make it into the finished game.

A team may experiment with a new character, weapon, level, mechanic, or animation style. The team needs to learn whether the idea is fun, understandable, and worth more investment.

It would often be wasteful to require perfect art, final audio, optimized performance, polished lighting, and complete balancing before the team learns whether the idea works at all.

So a game team might use levels of done like these.

Done Level 1: the Idea Can Be Evaluated

At Level 1, the feature works well enough for the team to make a decision.

For a new character, that might mean the character is animated in a simple test environment. The art is not final. The audio is not final. Performance is not fully tuned.

But the feature is not just a sketch or a promise. It works enough that internal users can interact with it and provide meaningful feedback.

The product question might be: Is this character fun enough to continue?

If the answer is no, the team can stop before investing in polish that would never be used.

Done Level 2: the Feature Is Integrated

At Level 2, the feature is integrated into the broader game.

Users can play with it in a more realistic context. The team can learn how the feature interacts with other parts of the product. New risks become visible.

The product question might be: Does this feature still work when it is part of the whole game?

Some ideas look good in isolation and fail when integrated. Level 2 helps the team discover that before making a larger investment.

Done Level 3: the Feature Is Shippable

At Level 3, the feature is good enough to include in a public release.

The team may still want to improve it. They may want better frame rates, richer animation, more refined colors, improved balancing, or more polish.

But they would not be embarrassed to ship it. Customers can use it. The product owner could choose to release it.

This is an important distinction. Level 3 is not “almost done.” It is shippable.

Done Level 4: the Feature Is Polished

At Level 4, the feature is tuned, polished, and as good as the team reasonably knows how to make it.

A typical public release might include a mix of Level 3 and Level 4 items. That is normal. There will always be areas the team would like to improve.

Level 4 is not the minimum standard for every feature. It is the level the team uses when extra polish is strategically valuable.

An Example from Hardware Development

I have seen a similar approach work in hardware development.

One company was building a suite of home automation products. At any time, dozens of components were in development. Some were early experiments. Others were installed in model homes. Others were nearly ready for sale.

For that environment, the team used levels of done like these.

Done Level 1: It Works on a Test Bench

At Level 1, the new hardware works in a controlled test environment.

This is not enough to sell the product. It is not enough to install it in a customer’s home. But it may be enough to answer an early question: Can this idea work technically?

Done Level 2: It Works with the Product Suite

At Level 2, the hardware is integrated with the other products in the suite.

The question is no longer, “Can this component work by itself?” The question becomes, “Can it work as part of the product system?”

That is a different and more valuable question.

Done Level 3: It Works in a Realistic Test Environment

At Level 3, the hardware is installed and running in a model home or other realistic beta environment.

Now the team can learn from real-world conditions. Installation problems, usability concerns, reliability issues, and integration surprises become easier to see.

Done Level 4: It Is Ready for Sale

At Level 4, the product is fully ready for sale.

That might include manufacturing readiness, regulatory approval, safety certification, packaging, documentation, support readiness, and whatever else is required for the product.

Again, the levels are not a way to avoid quality. They are a way to match investment to the decision being made.

The Test for Whether Levels of Done Are Legitimate

Before using multiple levels of done, ask this question:

Will we sometimes stop work at each level because we have learned enough?

If the answer is no, you probably do not need multiple levels of done.

If every item always moves from Level 1 to Level 2 to Level 3 to Level 4, the levels may simply be phases. And if those phases map to analysis, development, testing, and release, the team is probably recreating waterfall inside Scrum.

Multiple levels of done are legitimate when they help the product owner make better investment decisions.

For example:

• A feature reaches Level 1 and the product owner decides it is not promising enough to continue.
• A hardware component reaches Level 2 and the team discovers integration costs are too high.
• A game mechanic reaches Level 3 and the product owner decides it is good enough to ship without further polish.
• A feature reaches Level 4 because it is strategically important and worth the extra investment.

That is the point of levels of done: they create decision points.

They help the team avoid overinvesting in ideas that should be abandoned and underinvesting in ideas that deserve more polish.

Do Not Use Levels of Done to Lower Quality

The biggest risk with multiple levels of done is that they become an excuse for unfinished work.

A team might say:

• “It’s development done.”
• “Testing will happen next sprint.”
• “Documentation can come later.”
• “We’ll integrate everything near the end.”
• “It’s done except for performance.”
• “It’s done except for the hard parts.”

That is not a useful set of done levels. That is a list of undone work.

A legitimate level of done should still include the quality practices appropriate for that level. If a Level 1 prototype needs tests to make feedback trustworthy, include tests. If a Level 2 integration needs documentation for internal users, include documentation. If a Level 3 item is called shippable, it needs to be genuinely shippable.

The Definition of Done should create transparency. It should not create a vocabulary for hiding risk.

How to Try Multiple Levels of Done

If your team believes multiple levels of done may be useful, start carefully.

First, keep your current Definition of Done. Do not throw it away.

Then identify the real product decisions you need to make before full release readiness. Give each decision point a clear purpose.

For each level, define:

• What question this level helps answer
• Who will inspect the work at this level
• What quality standards still apply
• What evidence is needed before the work can be called done at this level
• What decision the product owner can make after seeing the work
• Whether the item may stop at this level

For example, a team might define a Level 1 done item as “ready for internal product feedback.” That level might still require code review, basic automated tests, integration in a test environment, and clear notes about known limitations.

The team should also agree on what Level 1 does not mean. It does not mean production ready. It does not mean releasable. It does not mean the work can be counted as part of a shippable Increment unless the team’s Definition of Done for that Increment has been met.

That distinction matters.

A Better Name May Help

Some teams may be better off avoiding the phrase “multiple definitions of done.”

Instead, they might use terms like:

• Learning milestone
• Validation level
• Release readiness level
• Product decision point
• Prototype done
• Beta done
• Release done

These names can reduce confusion because they make the purpose of each level more explicit.

The phrase “Definition of Done” has a specific meaning in Scrum. If using “multiple levels of done” causes people to misunderstand what is part of the Increment, use clearer language.

The goal is not to win a terminology argument. The goal is to create transparency.

Most Teams Should Keep It Simple

Most teams do not need multiple levels of done.

They need one strong Definition of Done. They need smaller product backlog items. They need better backlog refinement. They need more frequent integration. They need to stop carrying unfinished work from sprint to sprint.

But some teams work in environments where full release readiness is expensive, and where earlier levels of completeness support valuable product decisions.

For those teams, multiple levels of done can help. But keep in mind some cautions:

• Use them only when each level answers a real question.
• Use them only when each level has clear quality expectations.
• Use them only when work may reasonably stop at that level.
• And never use them to call unfinished work done.

The best Definition of Done, whether you have one level or several, helps everyone see the truth about the product.