713-909-6967 [email protected]

Definition of Done : Why it matters?

by | Jul 8, 2015 | Definition of Done, Favorites, Tools & Artifacts | 0 comments

One of the first things we recommend new Agile teams establish a “Definition of Done”.  A shared definition of “done” is crucial to highly functioning Agile Teams in helping them develop practices and behavior that drive quality, consistency and transparency.

Why it matters


A useful product has two key aspects. Features in this product are not only useful to users but are also usable, in other words, features actually work.

The product owner and stakeholders help the delivery team understand the “right thing” to be developed and the delivery team uses their development expertise to build it the “right way”. Both these dimensions are crucial for any product development.

check mark_ACvs.DoD cc-dhavalpanchalRight-Thing, Right-Way:These are features that are desired by your end-users and they work the way they are supposed to. These features are conceptually coherent with the product, and also built the right way, such that they are stable and do not cause technical instability in the product.

bugs_ACvs.DoD cc-dhavalpanchalRight-Thing, Wrong-Way: These are features that are desired by the users and they use these features. However, since these are not built the “right way” they do not function the way these are supposed to. When features are not tested they fail to perform their utility. When features are implemented without cognisance to end-user context and behavior, or when the team developing the features lacks *competence* and discipline, we create products that are buggy. These issues hamper the ability for end-users to get their job done and leads to waste and higher costs. As one executive, so aptly pondered out loud “Why is it that we never have time to do it right! but have time to do it again?”.

ghost_ACvs.DoD cc-dhavalpanchalWrong-Thing, Right-Way: These are the features that your end-users do not know exist. They may have been built the “right way” but then these features are not discovered and not used. These are ghost features that are silently increasing product engineering complexity. In Extreme Programming, the prioritization principle of YAGNI (You ain’t gonna need it) is intended to counter unfettered stakeholder desires and implement only features that are needed, now!. Deferring commitment for features is a good strategy since we all know, unlike tomatoes we don’t sell software by the pound.

maintenance_ACvs.DoD cc-dhavalpanchalWrong-Thing, Wrong-Way: Wrong features built the wrong way are cancerous cells that eat up developmental capacity since these cause issues with well functioning parts of the product. This causes erosion of development capacity for the team as the team gets sucked into bug fixes only to discover that issue stems from an area of the product that no one uses. These features erode team morale. Lack of team discipline has lead to accumulation of technical debt and feature creep creating an untenable situation. Such legacy areas in a product are universally feared.

The Definition of Done (DoD) expresses the “right way”, a checklist that asserts quality of the product and the workmanship of the delivery team. Acceptance criteria accompanying a User Story, or a feature requirement represent the “right thing”. Getting both these aspects of product development right are important for sustainable and continual product growth. It requires collaboration, trust and feedback with and among the delivery team(s), product owner and stakeholders.

Do you want to go beyond the basics?

If you found this article useful, join our Accelerate Advantage™ mailing list. Evolve Agility is founded on the belief that people care deeply about their places of belonging and are not afraid to take action. Join our mailing list to stay connected with a growing community of practitioners who believe in actionable learning.

Contact us to learn about our training & coaching services.



  1. Acceptance Criteria and Definition of Done - Collaborative Leadership Team - […] of Done and its relationship to Acceptance Criteria (see Ron Jefferies essay and a recent blog by Dhaval Panchal),…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

You May Also Like

The Conflict Escalation Ladder

The Conflict Escalation Ladder

Disagreements are not conflicts. Disagreements are a healthy part of a collaborative dynamic, but conflicts are not. The critical outcome is that people strengthen their relationships as they work through disagreements, whereas the result of the conflict is that...

Leadership stances for problem-solving

Leadership stances for problem-solving

A problem can be defined as the gap/difference between the things as desired and things as perceived. For example, it is close to noon, and I perceive hunger or rumblings in my tummy. I can attempt to close the gap/difference by making myself a sandwich or a salad and...

The Self-Managing Team Canvas

The Self-Managing Team Canvas

In our team coaching efforts we have used the Team Self-Managing Canvas to grow teaminess. Teaminess is not a dictionary word, yet 😉 Teaminess refers to a feeling of being one in effort, behavior, and communication toward achieving shared purposes. For teams that are...