The Definition of Done (DoD)

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

A Sample US DoD

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:

  1. All Acceptance Criteria of the User Story are met
  2. Code meets general Coding Standard (e.g. as defined in Checkstyle)
  3. Functional tests are performed by team members other than those working on the implementation of that feature
  4. Code is either reviewed or produced with a pair-programming method
  5. The code is covered by a minimum of 70% Unit Tests and all tests are Green
  6. Automated acceptance tests (Selenium) are prepared for the feature and are Green
  7. 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:

  1. All the User Story included in the Sprint are closed and meet the US DoD
  2. The agreed development freeze day has been met
  3. All Unit Tests, Automated Acceptance tests have passed successfully
  4. Regression testing has been performed on the product after the changes and
  5. 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.

Other DoD-s?

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
  • etc..

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!

This entry was posted in Agile, Automated Testing, Definition of Done, SCRUM, UnitTests, testing and tagged , , , , , , , . Bookmark the permalink.

25 Responses to The Definition of Done (DoD)

  1. Pingback: Tweets that mention The Definition of Done (DoD) | ReadMe -- Topsy.com

  2. Pingback: pakra it

  3. Pingback: Shravan Kumar T

  4. Pingback: Anonymous

  5. Pingback: Aldon

  6. Pingback: Narek Alaverdyan

  7. Pingback: Nune Isabekyan

  8. Is the post complete ?? Say done lolz.
    Good post .
    Its true that team’s definition of done is posted on a visible place .

  9. Pingback: Inetgate Writer

  10. Pingback: Dilipkumar

  11. Pingback: Jeremy Blythe

  12. Pingback: Suren Hiraman

  13. Pingback: Yan Avery

  14. Pingback: Jan Tanis

  15. Pingback: The Definition of Done (DoD) | Agile Software Development

  16. Pingback: Florian S

  17. Pingback: Philip Hartman

  18. Pingback: Akira Sakakibara

  19. Pingback: Is it Done? Is it Done Done? | Master of the Whiteboard

  20. Great post. I talked about your post in the Nashville Agile Users Group the other day. See also http://philiphartman.com/2012/06/12/done-done/

  21. Pingback: Наш процесс разработки: 50 месяцев эволюции / Blog.Vseznaut.ru

  22. Pingback: Sean Phillips

  23. Chuck vdL says:

    One thing that might be able to use a bit of elaboration is just what does product is tested mean in reference to the release DoD. My fear is that some might take this to ‘testing waits till before release’ which IMHO should not be the case, at least not with a majority of testing. That’s mostly a risk if someone is just looking at the Release DoD, outside of the context of the Story and Sprint DoD’s, but it does point out the importance of context. We already have a good amount of testing earlier, and in my view your QA/Test people should be participating in that.

    Since we have Acceptance, Unit, Functional, Integration all listed with user stories, along with Regression thrown in for the Sprint, what testing remains prior to release? (especially considering that story acceptance criteria could very well include Performance and Capacity/Load requirements)

    So what testing remains to be done prior to release? For many groups there may be a rollout to a staging environment, or some sort of installation testing. Another possibility may be longer duration tests to simulate running for days or weeks without a reboot which are not practical during an iteration.

    Does anyone have something more to add in terms of what testing takes place before release?

  24. Pingback: op

  25. Pingback: Definition of Done (DoD) for Testautomation | it-kosmopolit

Leave a Reply

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

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>