How to create a good User Story ? Focus on DOR & DOD

Here’s something you may have heard during a sprint: “If you need more precision in a User Story, come see me and I will explain it to you”. That’s a sentence full of good intentions, but a typical problem: because if a User Story is well designed, it doesn’t require questions or additional explanations.

DOR & DOD: what is it?

By not specifying your User Stories upstream, you’re taking the risk of having the specified functionality be different from the one developed. This challenge is summed up perfectly by the IT concept of “garbage in, garbage out” – which means that if the input data is of poor quality, the output result will also be of poor quality. This is how two terms appeared to define the minimum standard for a User Story to be viable before and after its development: Definition Of Ready and Definition Of Done.

📚 Read our article about agile sprints.

📚 Read our article on User Stories.

Definition Of Ready (DOR)

We can summarize a Scrum's Definition of Ready in one sentence: it is the state of a User Story at the moment the entire product team believes it’s ready to be developed. It is therefore a User Story ready to be assigned, sufficiently detailed for a developer to create it, and with the right acceptance criteria for it to pass the approval of a Tech Lead.

To write your Definition Of Ready, simply start with the basic acceptance criteria:

• an explicit title
• a description or value proposition (“As…I wish…so…”)
• an estimate of the load
• acceptance criteria

Once the basics are laid out, the most effective way to create a Definition Of Ready is to ask your team: what are the difficulties regularly encountered when reading User Stories? How have we wasted our time? Should we address these points first?

📚 Read our article on the Scrum methodology.

DOR: validate your User Story

Definition Of Done (DOD)

Definition Of Done Scrum: this is the state of progress of a User Story considered “ready to be deployed”.

This means, for example, that the entire User Story is produced, the code is validated by the Tech Lead and it has successfully passed the Product Owner's approval as well as the unit tests. But how do we proceed?

It is useless to paralyze our validation process with an endless list of checkpoints, but we will come back to this later. However, keep in mind that your Definition Of Done is insufficient if your User Story:

• does not pass the tests or is untestable;
• cannot be merged with the master branch;
• is impossible to deploy.

Your Definition Of Done must guarantee your User Stories a viability on a functional level but also in terms of product code quality.

Be agile, think easy

The Definition of Ready or the Definition of Done must not become an obstacle or too time-consuming a step during your ceremonies. You have to keep in mind that they are not Scrum ceremonies, see them more as indicators of validation.

Be agile and think easy. Establish four “bullet points” by definition at the start of the project. There are three advantages to this:

• the implementation of this skeleton of Definition Of Ready and Definition Of Done will be quick to implement;
• you will not erect a mountain of excessive checks for your product;
• by being concise, you will more easily gain the trust and buy-in of the team.

Obviously, it’s possible and even recommended to add acceptance criteria over time. By doing so, you will have a Definition Of Ready and a Definition Of Done adapted to your product.

Life cycle of a User Story

The recipe for a DOR and a DOD

It would be great to obtain the magic recipe of a Definition Of Ready or a Definition Of Done. Unfortunately, such a recipe doesn’t exist. Each product and project involves its own specificities.

However, it is possible to have a starting skeleton that you can support and complete.

An example of Definition Of Ready for a User Story can be at least:

• it was discussed by the Dev team and the Product Owner;
• its development implies real added value;
• the load has been estimated;
• this load fits into a single development sprint;
• acceptance criteria have been drafted.

An example of a Definition Of Done for a User Story can be at least:

• unit tests are validated;
• the Tech Lead's code review is validated;
• the dev branch is “merged” into the master branch;
• the functionality acceptance criteria are validated;
• the feature is deployed in QA (if you have QA teams).