General meaning of word done may seem obvious to everybody but once you start thinking about this, it becomes clear that done may have different meanings depending on the situation and personal point of view. In this article I would like to explore this issue in scope of software development.
Meaning of done from customer/stakeholder point of view
To understand the problem with word done let’s take a quick look at a simple situation when customer politely asks whether given feature is done. If we as a project manager (or product owner in Scrum) answer yes, the customer will immediately assume that it is all ready for deployment into the production system and will ask us to do so.
What if we used the feature in the test system and we are satisfied with it but we are still in the middle of QA process or still working on such things like documentation or translations? We would have to revert our statement and this would leave us in very bad light.
The problem here is that for project manager code is ready to be shipped and this is what he carelessly called done. However, the definition of done from the customer point of view is totally different because he expects the feature to be fully ready for deployment including complete testing, documentation, translations to name few.
Meaning of done from project manager point of view
Software developers, when asked by managers whether given feature is done, often answer yes while they have just finished implementation or are in the middle of testing, ensuring code coverage or documenting. To tell the truth I have caught myself doing this many times. However, the managers assume that all these tasks were finished when they hear word done.
Need for definition of done
Misunderstandings caused by different meanings of word done can be resolved by introducing explicit definition of done which will be shared by everyone involved into the project. This definition is usually a check-list of all things which should be successfully finished before we could call the feature or task done.
The example check-list may look like this:
- Source code is commited to SCM
- Source code is refactored
- Source code has right formatting
- Source code is documented (e.g. Javadoc)
- Source code is reviewed
- All units tests are passing
- All integration tests are passing
- All regression tests are passing
- All load tests are passing
- Source code coverage is high
- Documentation is updated
- Graphics are updated
- Translations are updated
- Plan how to demonstrate it to the customer is ready
Although the list may seem overwhelming, you don’t have to put them all into your own definition of done. Depending on your project, technologies, customer and other factors you may safely omit many things from this list (e.g. formatting of source code, load testing or translations). Your definition of done may also evolve over time and you may add new items to the check-list when needed. Also keep in mind that definition of done should contain reasonable minimum of things to check – don’t try to overdo this.
Explicit definition of done greatly reduce the chance of misunderstandings between development team, project manager and customer. Additionally, it increases code quality and also limits rework needed by ensuring that nothing important was missed.
At the end I would like to add that the same problem as with word done also happens for its synonyms (e.g. ready, finished, completed). Please, be careful when using them.