Knowing when a user story is complete
Have you ever been in the following situation? Your apartment needs a thorough cleaning and you decide to be the one to do it. When you tell your partner on the phone, they are ecstatic! Yet when they come home, rather than give you a big thanks, they run their finger over the top of a surface and show you the dust that remains. The place is cleaner - but in their eyes, the cleaning is not a job that has been fully done.
The same thing can happen in software development! Different teams or different members of a team can have different ideas of what it means for a piece of work (e.g. a user story) to be "done" and to be "ready for production".
Now imagine that you and your partner sit down and define a list for what a full clean of the apartment means! The checklist looks like this:
All floors vacuumed.
Kitchen floor mopped.
Dusting done on top of bookcase, fridge and TV.
Fridge emptied and all shelves cleaned.
Inside doors of fridge cleaned.
Now as you can imagine, the likelihood of one of you cleaning the apartment fully ("the cleaning is done") and the other disagreeing that the cleaning is done is much reduced!
What is a Definition of Done?
A Definition of Done is a checklist of activities that add value to the product which must be fully completed before a member of the team can refer to a user story as "done".
Here is an example 'definition of done' for a given user story below:
All of the automated tests for the user story run without failing.
Our QA (Quality Assurance ) team has tested this feature and not found any defects.
Our QA team has verified that all acceptance tests have passed.
The code was peer-reviewed (another member of the tech team looked at the code and was happy).
The Product Manager has tested and verified that they are happy.
The Code Quality score is at least 3.5 (assuming that some system calculates this score!).
No security issues have been found.
All documentation has been updated.
How to Define Done?
The best way to come up with a Definition of Done for your team is to sit together as a team and come up with a checklist that the whole team agrees upon.
Ask the questions 'what tasks would we always want to do' and 'what kind of checks would we always make' before pushing code to real customers ("pushing to production").
Consider any times previously that some team members referred to work as 'done' but other team members felt that it was 'not done'. What were the differences? Are those items that should be added to your Definition of Done?
If you have a dedicated Quality Assurance (QA) team that does all the testing of your products before release, what do they consider as important?
Many teams write automated checks (or tests) on their codebase so that they will know if some new code breaks any of the logic of the old code. If you have automated tests that run on your codebase, you will probably want to include that no new code breaks any old code. All tests should pass!
Do you have any automated systems that run on your code? Some tools like Code Climate can even provide you with a quality score and can scan your code for bad practices such as repeated chunks of code! If you have such tools, they can be incorporated into your Definition of Done.
Benefits of having a Definition of Done
There are many benefits to having a clear 'Definition of Done':
A checklist exists to make sure only high-quality work is released to real users.
Team members will have much less reason to argue over what "done" means.
User stories typically get finished (i.e. 'done') before more are started. This means fewer items that are 'work in progress' and more user stories are released to real customers.
Measuring 'quality' becomes part of the weekly/monthly routine.
Fewer items get 'pushed back' into development because they only 'make it out' of development when they are genuinely ready.
Fewer conversations like the one in the video below!
Writing user stories is a great way to create documentation that specifies the requirements of the business. Writing acceptance tests for each user story is an excellent way to define the scenarios that must be covered by the logic of a user story.
Acceptance tests are not the only thing that must be verified before a user story is pushed live. Rather, it is one fundamental part of what 'done' means and the team should define a full checklist of items which indicate when user stories are 'done'.
In this way, team communication, product quality and user experience all improve.
A video on Definition of Done by Dr Ian Mitchell