Definition of Not Done

The Scrum guide states, "When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment".

Typically, new Scrum teams draft up a Definition of Done as an exhaustive check-list of all the activities they do in order to mark an item as "Done". But is that the intention?

What "Done" actually means

The simplest Definition of "Done" is simply: "Done". This means that there is no more work to do. This assumes that the team is truly multi-skilled and can do all the work across the entire Order-to-Cash cycle of their product. For many teams, this is usually not the case. They leave items of work open that they can not do.

Abuse of "Done"

A typical DoD might look like this:

1. Specification
2. Coding
3. Build
4. Unit Testing
5. Deployment to Staging
6. Functional Testing
7. Integration Testing
8. System Testing
9. Exploratory Testing
10. All Tests Passed

Impressive. How busy these developers are! I never knew software development was so much work! (cough)
This Definition of Done gives the PO and/or business stakeholders a sense that the developers are doing a lot of work on even the most miniscule backlog item. 

As the team learns more over the product over time, this list is almost certain to expand. Maybe they will add items such as "Branches merged", "Bugs fixed", "Performance Testing" ...

But let's look at the Agile Principles: Simplicity - the art of maximizing the amount of Work Not Done - is essential!
We are not looking for a list of Work Done. We are not looking for effort justification! We are looking for ways of achieving the same goal with less work! A DoD might actually "lock in" a process which makes it impossible to eliminate unnecessary steps.

Living in a "Done" bubble

Did you realize that this DoD is missing something important? Yes - deployment to Production! And that may be no accident. Chances are that there are a lot of activities that are "out of scope" for the development team. They might lack the skills. There might be organizational constraints. In either case, the developers create an "illusion of Done": More work must be done, and they don't own that work.
The team has no autonomy to deliver real customer value - a clear violation of the 1st Agile Principle, and they might not even see how far away they really are from customer value.
From a business side, this is even more scary: The team produces a "Done" product and has no control over how much cost will still be incurred before there is any Return on Investment.

A DoD hides this problem in plain sight.

Fixing the Problem: DoND

The Definition of Done is not a justification for the business of the team - it is a way of managing expectations within the organization and towards customers. Customers don't care what the team is busy with - they want a Product!

The team can be more honest by turning the DoD upside down and clearly revealing what is not done. 

Rather than defining a DoD, the team should draft up the list of limitations which they can currently not do, turning this into the DoND.

For example, a DoND for the above DoD might look like this:

1. B2B Interface Specification (done by Architecture Group)
2. Configuration (done by Configuration Management Group)
3. B2B Testing (done by offshore Testing Group)
4. Deployment to Production (done by SysOps)
5. Data Migrations (done by SysOps)
6. Customer Feedback (done by Customer Service Group)

This makes it clear what risks are still in the product and how they are currently approached.

Eliminate the DoND

A DoND not only contains risk, cost and value delay, but also organizational complexity. A DoND is a clear list of impediments which Scrum Master and the organization's management must eliminate. A stratetic plan how to empty out the DoND and give the word "Done" it's intended meaning can only be implemented with the support of upper management.

Summary

Do not work to produce a DoD. Much less, implement the DoD as a checklist to work off.
Instead, create a DoND as the list of items the team still needs to gain control over to get things Done.

Take this list seriously and do whatever is necessary to boil it down to nothing. Only then will you have a truly self-organized team, which is yet another principle of agility.
Once this list is empty, your DoD will be very concise: "Done".