Let’s demystify these and agree on two criteria for your user stories (as well as other deliverables).

1. Definition of ready (DoR): A story doesn’t come into a sprint before it fulfils the DoR criteria. Teams need to agree on the amount of detail they need in a story before developers pick it up. Sometimes, teams may want to estimate the fully detailed story and compare it with any initial estimates they’d attached to it. This allows them to quantify scope change, if any.

2. Definition of done (DoD): These are a collection of criteria that the team must complete to term a story as “done”. This doesn’t just include business logic or acceptance tests. Depending on the team, the DoD can include logging, monitoring and even documentation.

Why do we need these agreements, you ask? Well, the DoR allows the team to set a standard for user stories that developers pick up. In an asynchronous setup, you need more detail in the story itself. That’s a good thing, because it leaves less room for ambiguity and it helps everyone in the team understand the requirement. The DoD ensures developers aren’t aiming for a moving target. It gives them a common standard to aim for with every user story.