How do we know when a user story is “done?” 

Can we say that the user story is done when it is coded and all acceptance tests for it are passed? Some business representatives may say yes, but they do not know all the peculiarities of software development because such criteria are not fully visible to them.  Another situation: a new feature that changed the business process was developed and tested according to the best software practices, but users struggle to use this feature because they are not sure about the changes. Maybe a proper user manual or user training is needed in this case?

Here comes a simple but very powerful technique called Definition of Done (DoD). The technique helps:

  • Identify all activities which need to be completed for the user story to meet the customer needs
  • Bring all participants to the common understanding of when the user story should be considered done
  • Reduce risks, as all activities are listed there is less risk that some activity will be missed

According to Agile Extension to the BABOK® Guide v2, Definition of Done is “a technique where the team agrees on, and prominently displays, a list of criteria which must be met before a backlog item is considered done.”

The best form of Definition of Done representation is a checklist of activities that has to demonstrate the agreed value and quality of a user story. This checklist should include certain acceptance and quality criteria.

Definition of Done may be defined for different levels of project work. For example, in the Agile/Scrum framework these levels of work could be user story, sprint, and release.

To sum up, the three main benefits of DoD are:

  • Decreasing Misunderstanding
  • Decreasing Risk of Delay and Budget Overrun
  • Ensuring the User Story/Sprint /Release Success
Tags: , , , , , , , , , , , , , , , , , , , , , , ,
Nikoleta Yanakieva Editor at DevStyleR International