Time and time again I see teams struggling with getting backlog items completed inside of their Sprint/Iteration (Scrum duration of time where the Development Team develops a portion of a product to be demonstrated, usually 2 weeks or less). Typically the business folks feel they have clearly defined a backlog item and feel the team should be able to easily implement it.

Well, unfortunately, that just isn’t the case sometimes.

Some of the items don’t have conditions defined that need to be met for the item to be completed. Some items have significant dependencies. When the team is asked if they know how to demonstrate the item, sometimes this is met with shrugs of shoulders or 5 different versions of how to demonstrate it are given.

So, what usually fixes all this? In my experience, creating a Definition of Ready (DoR) agreement and following it, does the trick.

What is the Definition of Ready (DoR)?

It is an agreement on the collection of conditions that need to be fulfilled in order for a backlog item to be considered in an upcoming Sprint/Iteration for delivery.

Why do we need a DoR?

If the team keeps pulling stories into the sprint/iteration that aren’t being completed, it is probably because the backlog items aren’t adhering to an agreed upon state they must be in to be considered for an iteration. Creating DoR agreement and following it will greatly increase the teams ability to complete backlog items within a Sprint/Iteration.

How to Generate the Initial DoR

1. Gather the team (including the business and development team) around a whiteboard. Explain that the purpose of the workshop is to create an agreement as to what needs to be known about a backlog item before it is considered for Sprint/Iteration planning.
2. Invite the team to generate various items that would be needed for a backlog item to be considered for planning. Allow 5 minutes or so for the items to  generate these items and when it feels like the group isn’t generating anymore, stop. You may need to add time if the items are still coming in at 5 minutes.
3. Have the team vote on which items feel critical to be considered. Give them 5 votes each and let them know they can place multiple votes on one item or spread them out as they see fit.
4. Sort the voted items in order of highest voted. The first 4-5 items should be no brainers to include in the DoR. I typically start at the 5 or 6 priority item and ask the team how critical they feel this item is. If the group feels it is, add and then move onto the next item, asking the same question.

Definition of Ready Example

• Clear Acceptance Criteria
• Has business value
• Small enough to be completed within a sprint
• Team understands how to demonstrate
• Necessary environments are available
• Content is finalized
• Testable examples
• External dependencies are identified and available during implementation time

Now we have a DoR, what do we do with It?

With the DoR created it is time to post it in very visible places. If the team is collocated then the DoR can be printed poster-sized and hung on the wall in the room where the backlog items will be refined/groomed. Additionally post it to an obvious place on the team’s collaboration/knowledge sharing tool (i.e. Jira, VersionOne, Trello). Other teams have created a DoR checklist on each backlog item in the tool.

Is the DoR Static?

No. It should evolve over time. If the team continues to struggle with completing some backlog items, identify if their is a common impediment that is causing this. If so, add a new item to the DoR that will ensure any further backlog items won’t be pulled in.

Alright, what are you waiting for, go put a meeting invite on the calendar to create your initial DoR and start putting it into action. Before you know it the team will be consistently delivering backlog items within a Sprint/Iteration. Good luck.