Definition of Ready

Dear Scrum Master, Don't let anything that's not READY into your Sprint.

Imagine, you are going to cook a meal for your spouse for your anniversary evening. Before starting to cook, you actually check, whether all the ingredients are available, you check if those are in the sufficient quantities, you buy out the missing things and then you start cooking, Right? The same is true for user stories.
User stories after their birth, have very tiny details. It is difficult for the team to commit to such stories. Team needs discussions, analysis, arguments and negotiations to groom the stories, so that the stories become matured and then team can commit to the stories.
But how does a team know, if the story is really ready to be taken into the sprint?
As user-story becomes clear and team doesn’t have any unanswered question and dependency remaining, the story is considered "READY". The list of items which help us to identify the "READY"ness is called as Definition of Ready (DOR).

Every user story must satisfy the INVEST criteria, before team commits to it. Every dependency

from the story needs to be removed, before team commits to it. All the necessary softwares and hardwares must be ready, before team commits to any story. These and many more items comprise into a list i.e. DOR.
Before committing to any story, the team can check if the story meets all the DOR criterion. If not they can reject the story, so that the stakeholders can put the missing details into it.
Agile promotes "Courage" as its core value. Courage to say "No" is important while committing for the stories. DOR gives us the sensible reasons to say "No".

How to build a DOR

Creating a DOR is a one time activity. But periodically (may be once in 6 months), you should re-visit the DOR and update it as needed.

Before your team moves into agile, (Or to update your existing DOR) do below exercise:

1. Educate your stakeholders about DOR. You can send them this blog link.
2. Send meeting invite to all the stakeholders of your team + the team with the notice saying "We will need to define our DOR, so come prepared with your checklist, which you would generally see before committing for any user story".
3. In the meeting, ask every one to write their items on a sticky note. Past all the sticky notes on a big wall.
4. Now, ask everyone to visit the wall, remove duplicates.
5. Now, pick a volunteer and ask him to read out loud each item from the wall.
6. Ask the team if they want this item in DOR. If not, why? If yes, why?
7. There will be certainly some disagreements, which must be resolved through discussions.
8. Then put all the agreed items in an xls, and store it on central location or post in on some big wall near to your team area.
9. This will be your DOR and your team should follow it for every story. If the story satisfies these criterion, then only commit for the story.

How to use the DOR

1. During sprint planning, pick the story for which you wish to commit.
2. Open the DOR on another screen.
3. Start ticking the items from DOR which are satisfied by the story.
4. Mark the items with X, which do not get fulfilled for this story.
5. Discuss and negotiate with PO and then commit or say no to the story with reasons.
6. The good way is say No if at least one of the criteria in the DOR is not fulfilled.
7. Mention the discussions in story, for future reference.

Benefits

1. You can proactively catch some of the impediments. E.g. your DOR may have an item saying "Is this story dependent on other team's work which is still in progress". And if you answer "Yes", then you can keep that story out of the sprint and can re-visit it in next sprint. If you would not have used DOR, then you would have committed for this story and then could have stuck up in the middle of your sprint, waiting for the other team's work to get done.
2. DOR gives team a confidence that they are making a sensible commitment.
3. DOR creates common understanding between team members and PO about what means "Ready". We do not want to commit for the stories which are "kind of ready" or "almost ready". We do not want to eat half-baked cake and suffer from loose-motions for next 10 days!

Pitfalls

1. Some teams try to make DOR as a law enforcement document and start rejecting every other story during the sprint planning and the sprint remains unplanned. This is the most common pitfall. While its true that DOR is checked for each story before committing, it is also true that every list item in DOR might not be valid for each user story. For e.g. your DOR might have an item saying "Is this story for integration with other application which is not in production", and you answer "Yes" and reject the story. But, most of the times, in real world, integrating applications are developed simultaneously. So this time, you would want to commit for this story with condition. So violate the DOR with condition. The condition could be "integration testing will get delayed".
2. Another risk is that we start pretending a frozen requirement with DOR. It's like saying that the user story is frozen, we know everything about it and nothing will change in the future in terms of requirements. What happens instead is that the user story can change for many reasons.So reacting to and embracing the change is still the key point and it should be part of the estimation and daily stand-ups.

As a good practice

• Before Sprint Planning, you can schedule "DOR check" meeting and have a look at stories at the top of the backlog. You can add a custom field named "Ready?" in your story management tool and mark it "Yes" or "No" for each story. This will help in quick sprint planning, the next day.
• While committing for the stories during sprint planning, when you will validate the story against DOR, you can attach the DOR to the story for record or copy-paste the DOR in notes section. This will help in future discussions about the story. This will avoid exclamations like "Ah! I did tell you that we would fail!".

Example

Click here to have a look at an example DOR.