.st0{fill:#FFFFFF;}

In Agile, Is There One Definition Of Done (DOD)? 

 April 19, 2022

By  Anthony Amos

There is no single DOD. It evolves with the product and the team’s capabilities. Some teams use DOD to reflect feature and function completion. But Scrum incorporates development operations into the DOD, which makes for a more complete solution.

The most incredibly beautiful aspect of software is that the product is never done.

Tony Amos

The most incredibly beautiful aspect of software is that the product is never done. Some products reach a point of stasis, but it is never done. So why bother with a definition of done (DOD)?

Well, consider a software product a collection of features. Those features evolve through a series of iterations. And each iteration can be considered “done”, until the next iteration is defined. This is where the DOD comes in.

There is no single DOD. It evolves with the product and the team’s capabilities. Some teams use DOD to reflect feature and function completion. But Scrum incorporates development operations into the DOD, which makes for a more complete solution.

For example, a mature team that has automated build, testing, and release processes may include extensive test scenarios in its DOD. A team that is just starting out may not have access to these tools yet, so they may focus on feature and function first, and make no mention of test standards in DOD. That’s not ideal, but it does reflect the team’s capabilities. The startup team must evolve its capabilities along with the product so that both the team and product mature in parallel.

I’ve seen too many teams push to develop the product as quickly as possible, leaving little or no room to grow the team’s technical abilities.

Without the mutual team and product maturity, over time the product becomes unscalable and untestable.

I look at the Definition of Done from two perspectives. First is the feature, or story under development. Its DOD reflects “done” for this iteration of the feature. DOD is not a final ultimate vision. Rather, DOD reflects what can be completed right now in this Sprint or Iteration. It is not the ultimate product, but it is a step that confirms our progress toward the final product.

The second perspective is the development platform standards. It is typically impractical to build out a full DevOps platform with automated build, test, and deployment for a new product MVP. At the same time, the team will be quickly overwhelmed with manual testing and deployment on a production system with thousands of customers. The development platform has a starting point and grows along with the product. DOD, as part of feature development, will also reflect this growth.

In my work with development teams, I encourage the use of DOD to support team growth. The DOD can include test cases that encourage automation or define performance criteria across many operating environments or browsers. Most teams would struggle to meet such requirements through manual efforts, thus exposing a business driver for automation. When used effectively, the DOD is a powerful tool for product owners, stakeholders, and team members

Anthony Amos


Anthony started creating software in 1981 when he curiously picked up the programming manual for a Wang OIS Word Processor while deployed with the US Navy. He had never seen a computer before, but he taught himself how to write programs that made his Navy work easier and more accurate.
After his honorable discharge in 1986, he began creating financial and analytical software for diverse organizations including Verizon Wireless, JP Morgan Asset Management, GoldenTree Asset Management, NASDAQ, Prudential Insurance, AT&T Capital Corporation, Lehman Brothers, Ernst & Young, and Blue Cross & Blue Shield of New Jersey.

Demonstrating his commitment to the principles and values of Agile Software Engineering, Anthony is a recognized SAFe® version 5 Program Consultant and holds many of the most challenging and difficult to attain Agile certifications. His practice is grounded in Agile Frameworks as he leads clients to implement Scrum, Kanban, Scrum with Kanban, Scaled Scrum with Nexus, and Scaled Agile Framework. He believes in using the framework that best fits the organization's cultural and business direction while maintaining disciplined processes.

Tony Amos

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our Agile newsletter