In Agile, Is There One Definition Of Done (DOD)? — Anthony Software Group Scrum master questions
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
Originally published at https://anthony-software-group.com on April 19, 2022.
