Definition of Done (DoD) and Quality - are they the same?

The concept of Done and its definition is general can and will vary based on teams and teams definition , but overall, from what I have read and experienced in implementing SCRUM, you have the following concepts making of DoD or a variation of the items below.

1. Short Spec created
2. Coding/Unit Tests created
3. Acceptance Tests created
4. 100% Acceptance tests passed
5. Product Owner demo passed
6. Known bugs fixed

I think that DoD is actually dynamic in nature and depends on business needs, schedule and risk, the definition of Done can change however there is a component of software that in my mind is a non-negotiable which is the concept of quality. So how can we balance the notion of quality, definition of Done and meet deadline delivery and promise of "potentially shippable software".

I think the answer lies in making the right tradeoffs in terms of risk and having the right strategy in place in understanding feature complexity, ability to break things down into small consumable features that allow the team to achieve the level of confidence which includes QA and development and having the key indicators to be there. I believe that pushing quality up the chain in the development cycle is key , by having continual integration in place, understanding the user story in detail, so that unit tests, QA plans and code reviews as well as bugs address quality fundamentally early on.

Just because you have a definition of Done agreed to, doesn't necessarily mean you will get the quality you need out of the feature set and release you are looking for.

thoughts and comments welcome, and my final contribution in the post is a great book about the pitfalls of development which I think many people already are aware of, which is a great read :-).


Code Complete: A Practical Handbook of Software Construction

Comments?