Working, Reliable, Valuable: Levels of Done Explained

Updated: Use this simple checklist to understand and improve your Definition of Done. Reliable, usable, and valuable products are the foundation of success. Start with where you are, then improve from there. And remember, success requires attention to results beyond the end of the sprint.

Not Done

Don’t kid yourself. If you hear these, it’s not done.

• Ninety percent done. As the saying goes, the first 90% of the work, takes the first 90% of the time. The remaining 10% takes the other 90% of the time!
• It Works on My Machine, as in “It works on my machine, but I have no idea whether it works anywhere else.” Another code word for, “it is not done.” Aim higher.

Working

• Functional – “validated against our acceptance criteria.” The first step to really done.

Reliable

• Inspected: The team has reviewed and improved the code to ensure it meets quality standards.
• Integrated: All components of the product work together.
• Automated: Repositories and test suites ensure that it still works even after making changes.

Usable

• Deployment Ready: Whether to deploy is a business decision, not a technical one.
• Reviewed by Users and Customers. Your first line of defense against building the wrong thing.
• Deployed: It has been put into service or for sale and can be released to customers or users.

Valuable

• Usage: Released to customers or users (and you are measuring)..
• Valuable: Our hypotheses about usage and value generation have been confirmed.
• Optimized: Often the first step in development is to create a capability. Improvement in ROI, usability, reliability, etc., may require further iteration on the solution

Definition of Done in Scrum

In Scrum, ‘Deployment Ready’ has been the minimum standard for Done in the sprint. Until the 2017 version of the Scrum Guide, Scrum called this “potentially shippable.” This generally entails Working and Reliable, but Scrum leaves it to the Scrum Team to define. The 2020 Guide defines Done as the minimum quality standard. In either case, the idea is that

High performance teams look constantly for better ways to deliver reliable, valuable products to their users and customers.

Deployed vs Released in DevOps

As teams seek to release more frequently, a more nuanced approach to releasing software has emerged. Deployed means the functionality has been installed in a production environment, but it has not necessarily been made available to users. Released means the functionality has been made available to users. The can be a selective process, by using run-time switches or by directing traffic flow to different instances of the system. Both approaches enable a smooth roll-out and easy roll-back if the release turns out to be a bad idea.

Done and the Sprint Review

How done is your software? I believe the conversations in the Sprint Review give a clear indication. Are you mostly discussing…

• Bugs vs features? – You are having issues at levels 2 through 4, Reliability.
• Whether features are done in this Sprint? – You have not achieved level 5, Deployable.
• What changes will be beneficial to product? – You are somewhere around level 7, Deployed.
• The business value created by recently released features? – You are at least at level 9, Valuable. Maybe this isn’t a Sprint Review any more, but more of a product review.

Achieving a good definition of done

Defy Mediocrity! Harness the full potential of Scrum with the Definition of Done. Download the infographic, then start a conversation! Check the boxes to ensure high quality and high performance. Keep raising the bar and ensure that you really live your Definition of Done.

What is in the Definition of Done in your team? How many boxes can you tick? Where do you pretend to check the box, even though you really don’t? Join the discussion on LinkedIn!

Update: After receiving much constructive feedback on the LinkedIn post, I have updated the infographic. I think I will never call a release “final” again! Each release is merely the basis for further optimization. Here is the original “final” version, which should have been named “RC1”: Full PDF, Checklist, Explanation

Second Update: Now up to RC3 (PDF, JPEG) of the graphic. More feedback, this time centered around DevOps and the definition of Deployed and Released. This lead to insights about team maturity and the Sprint Review. In the article, I clarified the section on Scrum and the Definition of Done, and added the sections of DevOps and the Sprint Review. RC3 of the graphic has improved graphic design (more white space), corrects a typo, and updates the small text to reflect the DevOps approach. It is renamed Levels of Done rather than Definition of Done, to avoid confusion with Scrum’s Definition. Here is RC2 if you still want it!

Thanks to Cliff Berg, Peter Michael Moore, Sky Chin, and especially Robbie Kouwenberg for their insights and support in creating this version!