What is a Definition of Done?
Definition of Done is a crucial element of a successful scrum software development. When defined and followed, makes sure that when someone says that a task is done. There is an explicit understanding what it means.
For completeness and integrity you would have 3 different definitions of done: for a User Story (a feature), for a Sprint and for a Release. This is also in line with the SCRUM Alliance recommendation.
A User Story Definition of Done
So, let’s pick the User Story DoD, and elaborate more. The User Story DoD’s can be
random and different, but usually a significant number of points are shared across all different US DoD-s followed by different companies.
An example of US DoD has the following activities:
- All Acceptance Criteria of the User Story are met
- Code meets general Coding Standard (e.g. as defined in Checkstyle)
- Functional tests are performed by team members other than those working on the implementation of that feature
- Code is either reviewed or produced with a pair-programming method
- The code is covered by a minimum of 70% Unit Tests and all tests are Green
- Automated acceptance tests (Selenium) are prepared for the feature and are Green
- Integration tests of the affected areas are conducted and passed
As any other set of rules, there is also a basic meaning behind all of the activities defined in this Definition of done. The meaning is that the feature implemented meets all the requirements of the User Story, that the coding has been performed in compliance with the shared and agreed coding standards. That someone else, rather than the person who implemented the feature has performed a functional test on it. That the code has been reviewed, or by using pair-programming ensured the code has been double-checked, not to allow bad syntax, magic numbers, as well as to make sure the architecture style is in line with the rest of the system. The Unit tests and Selenium tests have been prepared to reduce the human involvement in the testing phase, and to aim for a complete automation of testing. Also it is made sure that for every feature developed, an integration tests has also been carried out, to make sure it fit the system well.
All of these activities are aimed to one big target which is improving the quality of the system. Since in SCRUM the team itself is responsible for quality, not a separate quality assurance team, it is essential for the team to invest time and activities on ensuring the quality of the product.
This is only an example of a User Story DoD. DoD is also great if you want to do an activity only temporary.
For example: if the team has a module that has no automated tests at all, the team may want to make sure that module is paid a special attention to.
These are working agreements, some of which are static and never change. The rest can be dynamic, also new agreements may be included and excluded from the list. The retrospectives are great time to discuss the DoD, and change if required.
[It’s important simply to start employing the DoD practice, even if only 1 or 2 activities are included in the list. The DoD is not static, it evolves, grows and if the teams are committed, competent and appropriate supporting tools and environment the team will hold a DoD that is a big step forward in creating a Shippable Product every sprint and making sure the defect rate is minimum.]
Sprint Definition of Done
The sprint is an iteration of software development with an aim to deliver a shippable product in the end. The Sprint DoD is to help this target to be achieved: for example by making sure that:
- All the User Story included in the Sprint are closed and meet the US DoD
- The agreed development freeze day has been met
- All Unit Tests, Automated Acceptance tests have passed successfully
- Regression testing has been performed on the product after the changes and
- No Critical or Blocker bug exists in the bug backlog
This is an example of a Sprint Definition of Done. I am sure many of the activities sound familiar. Again this is tailored by the team on their team processes and practices, but usually and simply it needs to be started with even a couple of agreements, later it will evolve into what the team will come to understand an indispensible part of their daily work.
The last of the Scrum Alliance recommended DoD-s is the Release Definition of Done.
The release DoD is straightforward to think about and would most likely include activities like
- making sure the product is tested,
- making sure the configuration changes are ready
- that a backup has been made
- a tag created for a release
- the possibility of rollback with related risks have been provided
From my experience working with DoD-s there is one particular place where DoD may also make sense to be introduced. It is when a defect/bug is fixed. I would call it a Bug Definition of Done.
It would include the following:
- the defect is fixed
- if missing, Unit Tests are implemented that covers the fix’s code functionality
- a functional test to cover the bug is performed by a person other than the person who fixed the bug
- an automated test is created that checks the flow
The reason I see this beneficial is that if with every bug fix missing unit tests are written, as well as the automated script is generated the coverage of both code and functionality will significantly increase, meaning better product robustness and increased quality.
It is also very important to post the team’s definition of done on a visible place, where everyone is reminded of it every time!