What does "done" mean to you? I find that my definition of "done" continues to expand. When I was still pretty green, I would say "It's done" when I had finished coding. (Later, a wiser and more cynical colleague taught me that "done" meant that you had not only finished the work, but made sure to tell your manager you had finished the work.)
The next meaning of "done" that I learned had to do with version control. It's not done until it's checked in.
Several years ago, I got test infected and my definition of "done" expanded to include unit testing.
Now that I've lived in operations for a few years and gotten to know and love Lean Software Development, I have a new definition of "done".
Here goes:
A feature is not "done" until all of the following can be said about it:
- All unit tests are green.
- The code is as simple as it can be.
- It communicates clearly.
- It compiles in the automated build from a clean checkout.
- It has passed unit, functional, integration, stress, longevity, load, and resilience testing.
- The customer has accepted the feature.
- It is included in a release that has been branched in version control.
- The feature's impact on capacity is well-understood.
- Deployment instructions for the release are defined and do not include a "point of no return".
- Rollback instructions for the release are defined and tested.
- It has been deployed and verified.
- It is generating revenue.
Until all of these are true, the feature is just unfinished inventory.