Definition of Ready

How do you help your Scrum Team get better?

We have talked about the Impediment List.

Now we talk about the Definition of Ready, the lack of which would be an impediment. One of the Top 20 impediments I think, almost any time.

Is the Definition of Ready well known?

I think not. And even if known, not done often or not done well.

It's actually a big subject, but let's cover some of it now, in this article.

Some key ideas:

• Maybe the first idea is that we will build "requirements" iteratively and incrementally, as we build the product. A rolling process.
• "Unclear requirements" is one of our biggest problems (possibly not true for your Team, but I would still be a bit surprised).
• The Developers (Doers, Dev Team) get to decide if they have all the information they need to finish the story in the Sprint. In that way, they get to volunteer for the story (and for that matter, volunteer for how many stories or how many story points they think is reasonable in the coming Sprint).
• Giving these knowledge workers this level of control over their own work is good. Among other things, it improves morale (or motivation), which is so important for knowledge workers. But, really, only they know the information they need to be successful.
• The Product Owner and the "minions" (my charming name for the 1 to 20 people who help the PO pull all the details together) must provide most of the details. The Developers or others might provide details in some technical areas.
• Do NOT tell the Developers what they already know. Only what they need to know or be reminded of. Pictures also are good (with discussion).
• If the Developers know more, then they get more done in the Sprint and there are fewer questions for the PO to answer. If there are fewer questions in the Sprint, then the questions should be answered more quickly. That also improves Team productivity.
• This is a learning process. The PO is learning what the Developers know or don't know, and which types of information each person needs. And everyone will see communication fail, and, among other things, should tweak the DOR process so that communication is better next time.
• It is also a learning process because typically each Sprint has some new work that is dissimilar to work we have done before.

How would you start doing this?

I recommend a team meeting for maybe 30 minutes. You talk about the DOR idea and a simple DOR process.

Then the Developers can name specific small things they might need for certain kinds of stories (or, possibly, for all stories). And also the PO and the business stakeholders or others on the business side can mention small things that they are used to providing.

Agree NOT to provide things that are not wanted (although you can try to convince the Developers that they should want the X list).

Agree that early on (2? sprints before those stories will go into a Sprint), the PO and the Developers will pick and choose from the list what exactly to get for story 61. And then again for each successive story in Sprint N.

Agree that the Developers can ask questions all along the way, but will TRY hard to identify their information needs as early as possible. So that it is easier for the PO and the minions to get all the information by the end of those 2? sprints.

Three final reminders:

• Do not write down what the Developer already knows.
• Give the Developers the most important information, typically in lists or pictures.
• The Developers get to decide if the information is good enough.

***

Once you learn how to use the DOR and your DOR process, and the PO has enough help, your Team will become more productive (increased Velocity), there will be less stress, and the Team will be having more fun.

***

QUESTIONS:

1. Do you like the idea?
2. What else do you need to do it successfully? And help your Team become more successful with Scrum?

***

Note on the picture: The PO might use stickies like that to track the different details to collect for one story. I'm thinking roughly 5 stickies per story. Tell us if you have a better method.

Note: You can read more about this in the "Enabling Spec" and "Definition of Ready" patterns in A Scrum Book by Sutherland, Coplien et al. Or at ScrumPLOP.org