Definition of ‘Done’

During the last Agile SW Development Practices Seminar in Vantaa the participants shared a set of stories about how the switching to the agile development methods proceeded in their companies. A reasonable amount stories included a mention about that without the agreed definition of “done”, nothing was completely done.

Own experience

Few weeks ago, when starting a new project, our team decided to try figuring out what our ‘done’ means. It was a total surprise to discover that within a small and rather coherent team of five persons we had three different points of view.

Importance of ‘done’

People are different. They have different experiences and perceive the software development projects from the different perspectives. When developer tells that this or that feature is implemented, he often means, that all the functions are implemented and are ready for optimization, refactoring and extensive testing. On the other hand, when customer or manager hears that the feature is implemented, he often expects it to be ready for the release. This inconsistency can lead to the system composed of inconsistent components: half-tested, half-documented, half-optimized and eventually half-ready for the release. That’s why an explicit and concrete definition of “done” is the small, but important checkpoint in the software projects. Pay attention to this issue, talk it over with your boss and your customer. As a result of a rather small effort investment, you’ll have much getter grounds to describe the project state. A typical definition could be as simple as: “‘Done’ means, that the feature is implemented, reviewed, unit tested, but not necessarily documented”.

What do you think? Do your customers always share your point of view on what the “feature is implemented” means?

6 thoughts on “Definition of ‘Done’”

  1. Do your customers always share your point of view on what the “feature is implemented” means?

    I don’t think they do, but I find that we get best results when I press to get as real feedback as I can when finishing off a feature. So in the best case, I get approval from the customer and positive feedback from the actual end user of the feature.

    1. Providing value is the most important, I agree. However, it’s very good to know what exactly has been provided, isn’t it?

      Do you mean, that you are trying to do that detailed reporting that you don’t need this kind of definitions? In other words what ‘done’ means is defined in your every report?

  2. Your comment that on a team of five there were three distinct viewpoints about the definition of ‘done’ is an important point. A team must have a consensus about what ‘done’ means.

    One definition I’ve heard is to say a feature is done when it is ‘potentially shippable.’ That is, even if the project as a whole is not ready to deploy to production, the pieces that are considered ‘done’ are in good enough condition to deploy. Of course, this must be defined more precisely for each case.

    When the customer/user is satisfied with a feature, I think that is only part of the equation. Customers are unlikely to mention (or be aware of) non-functional requirements. There will be non-functional requirements of a technical nature, such as recoverability, performance, security, and so forth. There may be regulatory requirements, for example if the business domain is in the financial or defense sector. There may be organizational standards for UI look-and-feel or for standards compliance. A feature is not really ‘done’ until it satisfies non-functional requirements as well as customer-requested functional requirements.

    1. Excellent comment about the need to satisfy the non-functional requirements also!

      Unfortunately, the need to have a consensus on what “done” means is not that evident idea to everybody. In my case, after some arguing we decided to explicitly list the components of “done” in the task list. For example, there are items like “Code initial implementation of the mini-feature”, “test this mini-feature”, “run the code analysis tool and fix its warnings”, etc. It is a bit more clumsy, than just “feature done”, but defines the concrete requirements at the same level of precision

      “One definition I’ve heard is to say a feature is done when it is ‘potentially shippable.'”
      I also like this definition from the Scrum process very much. However, not everybody is ready accept the whole idea of potentially shippable increments.

  3. Yeah, that can be quite a reminder to “remain green always”. I wonder if it helps to put the whole definition of done to a T-Shirt 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *