In Scrum (or other methods), we like to propose complete user-stories so that the final work is in the best possible quality. A user-story is not just a simple “story friendly” (As [persona], I want [wish] so that [goal]). In order to adapt to the context and to work as a team, agile coaches really like to make a workshop to define the “Ready” and the “Done” that allows to make the Definition of Ready (Dor) and Definition of Done (Dod).
Version française: Definition of Done (DOD)
Who will define the Definition of Done?
The Agile coach will bring together the development team (or teams in frameworks such as LeSS or Nexus) and the Product Owner to work on the Definition of Ready and the Definition of Done.
Definition of Ready
How to define a user-story that is ready to be supported by developers (in the “TODO” column)?
We will ask developers to give their requirements on the definition of a user-story “READY”. The Product Owner is a consultant because he can help the team with his very good ideas.
The ideas that we often find:
La user-story doit être INVEST : user-story “Independent”, “Negotiable”, “Valuable”, “Estimable”, “Small” et “Testable”.
I think that all user-stories should be INVEST for quality reasons. However, it is important that developers agree with this idea (or even the Product Owner).
Do tests of acceptance: what are the tests to do to validate that the user-story is valid?
User-stories in hypothesis and measure mode: these 3 sentences allow concretely to make it possible to work in a Lean Startup mode. It is very interesting for the developers to understand the basis of the user-story that we will create:
"We believe that ... We will be right if ... What we did .... "
It must be understood that this addition takes time for the Product Owner because it involves more work; but it’s important for the Product owner to share the project’s vision or even the evolution of it.
Here is a small concrete example:
"We believe that smartphone has become indispensable to sell products We will be in the good way if 30% of our customers would like to buy our products with their smartphone What we did: work on a mobile app to meet the demand"
We could create a “Hypothesis and Measure” for Epics, personas, user-story units … It’s essential that each user-story is associated with one of the defined Hypotheses and Measure.
Definition of Done
The Product Owner and the developers together define what will be a user-story “Done”; basically, those are the criteria to validate to allow the Product Owner to place a request in “Done”. They will do this work together in a workshop to define the Definition of Done.
It is advisable to put acceptance tests in the definition of ready and their validation in the definition of done (because it’s dangerous if the Product Owner write them during the sprint).
Unit testing: a technique that allows to test each function separately to ensure that it functions properly every time that the product send in production. The interest of this request is especially for the Definition of Done.
In the definition of done, you will also need to define whether your code will be in recipe environment or production environment. The reflexion about the subject “putting into production” to know if the team include it or not in the criteria of Definition of done is a very important.
Conclusion definition of done (dod) in scrum
The Product Owner and the developers will themselves define the quality of the expected work. For that, they will define the Definition of Done and the definition of Ready.
What are your practices at home to define a user story ready and a user story Done? Share your tips on the definition of done (dod) or the definition of ready (dor).