What "Done" means?

Is it Done? This topic that is constantly reoccurring in the (agile) software development community.

Done is a magic keyword, with different meanings for different people.

• For a business owner, Done means that the product is running and serving Customers
• For a project manager, Done means that the code is implemented, tested in all testing cycles and delivered
• For a development manager, Done means the code is implemented according to standard, commented, unit tested and deployed in testing environment
• For a developer, Done often means that the tricky algorithms work, code compiles and was checked into Source Control. The HARD part is over and the code CAN run.

Here's a sample definition of Done for a Task (via scrumalliance) :

1. Coded/implemented
2. Peer reviewed (pair programming counts as peer review)
3. Code is run against current version in source control
4. Code is commented in source control and checked in
5. Code is commented on Public/Friend methods
6. Story/use case manual test plan updated
7. Unit tests written and passing
8. Build and package changes are communicated to build master
   
9. Task list hours are updated and task is closed out
10. All to-do items in code are completed

We need to establish a scale of Done, so that we can rate our "donnes" clearly, just like a good stake house does.
Oh, Sorry Sir, you didn't ask for a rare rib eye? My apologies, let me fix it for you! (The staff in a good stake house doesn't usually point out that the meat is properly cut, is very well seasoned and the last piece missing is a bit more heat. The stake is simply not done well).

In agile development, Team has a lot of sovereignty to make decisions and drive the implementation of Tasks. It takes an ownership of the Tasks and makes the implementation as good as can be.

But the Team also needs to clearly communicate the level of Done, as different stakeholders have different expectations. Only when the communication is clear, factual and correct the mutual trust can foster.