Done Done: It ain't over 'till it's over!

In the Scrum.org Headquarters there is a picture of Ken Schwaber - one of the founders of Scrum - pointing at a sticky saying "Done." This picture underscores the most essential rule in Scrum: create "Done" increments every Sprint.

Many people assume Scrum is only about building software. In reality, Scrum is a framework for delivering value in any complex environment. Scrum Teams can build products, services, or outcomes—anything that requires collaboration, iterative improvement, and risk reduction. For example, Scrum has been applied successfully to marketing campaigns, event planning, healthcare processes, machinery development, and even writing books. The principles of creating "Done" increments, inspecting, and adapting remain the same, no matter what the team is building.

But many teams struggle with this rule. It is tempting to fall into "shades of Done." An increment is considered "Done" by the Development Team, but requires further testing and stabilization in the next Sprint. Or work is considered "Done" by the Development Team, but the install package still needs to be created. Or work is considered "Done," but acceptance testing hasn't been done yet.

"Done" doesn't support adjectives like "nearly," "pretty much," or "almost." An increment is "Done" or it isn't—there is no gray area. And there is a very powerful, compelling reason behind this: the Scrum Framework only helps reduce the risk of wasted effort when you deliver "Done" increments every Sprint!

Essentially, a "Done" increment is a version of your product that is, or can immediately be, released to users and is valuable to them.

If you are unable to deliver a "Done" increment during a Sprint, you are not doing Scrum!

This is clearly explained in the image directly below. Click the image to see what happens if this problem continues sprint after sprint.

Defining "Done"

What constitutes "Done" depends greatly on context. Building a website for an external customer will require different work than working on mission-critical software for internal users. It depends on your organization’s quality guidelines, the criticality of the product, the level of user involvement, the technologies in use, and many other factors.

Suppose you are building a new feature for your product during the current Sprint. This requires a workflow of tasks—from writing code to creating unit tests, from designing to testing on mobile devices, and from user testing to integrating with other teams’ work—ultimately deploying it to users. It demands diverse skills in the Development Team and an effective workflow to accomplish everything within a single Sprint.

New Scrum Teams often struggle with this. It can be tempting to define "Done" as only what the team can realistically achieve in a Sprint, such as:

• Code peer-reviewed by another developer;
• Unit tests written and passing;
• Code merged and checked into the development branch.

While this may seem sufficient, it does not always result in a truly releasable increment.

"Done" and Undone Work

A Development Team may believe they are delivering a "Done" increment every Sprint. After all, they can tick all the boxes. But focusing only on working code often leaves the increment incomplete from the Product Owner’s perspective. The remaining steps—testing, integration, scaling, deployment, or documentation—may get discovered in future Sprints. Some examples:

• The Product Owner discovers missing features promised to stakeholders;
• Users report critical bugs that require fixes;
• Code integration with other teams fails, creating complex merge conflicts;
• The feature doesn’t scale correctly;
• Deployment fails due to missing dependencies;
• Security scans reveal vulnerabilities;
• Performance issues arise post-deployment;
• Missing documentation triggers support calls;
• The feature proves unusable for certain user groups.

This undone work disrupts future Sprints, decreases transparency, gives a false sense of progress, and maintains high risk. Over time, it erodes stakeholders’ trust in the Scrum Team.

Three examples to illustrate the point

• A Scrum Team customizing machinery software involved users early but rolled out late, encountering hardware issues that negated previous investments;
• A product team invested heavily without exposing it to users, and demand failed to meet expectations;
• A small Development Team building a website observed that only fully "Done" items generated useful feedback from stakeholders.

These examples show that releasing increments to users early mitigates risk and highlights the importance of collaboration between Development Teams and Product Owners in defining "Done."

Definition of Done as a "risk detector"

In Scrum, a complete definition of "Done" is your most powerful risk detector. It reduces undone work by making all required steps transparent and exposes impediments preventing the creation of "Done" increments every Sprint.

Now what?

Creating "Done" increments every Sprint is challenging. Key strategies include:

• Maintain a ruthless focus on "Done": Only include items in the Sprint Backlog that can result in a potentially releasable increment.
• Make the gap transparent: Identify what should be done versus what can currently be done and address impediments.
• Make it smaller & simpler: Focus on smaller increments that can be completed fully within a Sprint.
• Focus on risk reduction and value: Scrum is about reducing risk, maximizing value, and exposing impediments.

A hard truth

If you cannot deliver a "Done" increment every Sprint, you aren’t truly doing Scrum. Maintaining focus on "Done" makes obstacles highly visible and allows teams to adapt quickly.

Thanks to the Liberators for the above. Excellent work!

Also thanks to Head First who supplied the quick one page summary below: