Have you ever witnessed a situation where despite the team’s best efforts, diligence and meeting quality goals (Definition of Done) the customer is disappointed with the results of your work?

If yes, it is very likely that the refinement process doesn’t work as well as it should, and you should have a closer look at your entry criteria before starting work. The very fine example of such criteria is Definition of Ready (DoR).

So what exactly is DoR? In some simple words, it should help us to get to the point where a unit of work (User Story or any other Product Backlog Item) is “mature” enough so the implementation of the requirements can begin and the need behind it can be successfully satisfied. Fulfilling provisions of DoR gives you the green light to start the work – the Unit of Work becomes actionable.

And you may ask why does anybody need this DoR?

Why do you need Definition of Ready?

Imagine your team gets a task and they are to start working on it right away. How many times will they stop in order to get more info regarding the requirements, specify things, get the feedback on the way they perceive what needs to be done? Or on the other hand, how often would a customer, PO (Product Owner) or other stakeholders come over, changing their mind?

That all leads to the terrible waste of time. The team, instead of working, needs to block/put on hold their work to resolve the issues. All this should be done before the task finds itself on the team’s board. If not, a lot of time will be lost to search for the answers, context switching, etc.

As you can see, this extends the whole delivery process, its costs and decreases the predictability of delivery, which is especially valued by the business.

Refinement and Definition of Ready

Refinement is a process that leads to fulfillment of the Definition of Ready. Steps in the refinement should correspond to the points in the DoR, so you can treat it as a checklist.

So what steps should actually be taken to have a valuable refinement process and a good Definition of Ready? Here at Setapp we very often refer to the following things:

1. Breaking down the requirements

Breaking down the requirements into smaller Units of Work (User Stories, tasks). Smaller, in this case, means more predictable. Less unknown, easier to estimate. Very likely to deliver within one iteration/Sprint/cadence.

2. Creating acceptance criteria

Working on understanding what needs to be done in order to satisfy the needs behind the requirements. On one hand you can say this is a “Spice Girls moment” (“Tell me what you want, what you really, really want!”), so the PO / Customer can express and specify what is needed. On the other hand developers can receive feedback on their understanding of what they think should be delivered.

In order to increase chances of success, mutual understanding is needed. The best way to achieve it is to allow both sides to meet in person. May I just quote Agile Manifesto here:

“Business people and developers must work together daily throughout the project”

3. Look for impediments

Look for potential impediments, like dependencies or other blockers. If you find any, go and talk to the people, who can handle them. It makes no sense to begin with your work until they are not ready with theirs. Or at least receive (more or less) a confirmed deadline, so you would know how to arrange your own plans.

It would be good to follow up, to check if everything goes well. You may visit other team’s Daily meetings or catch them during coffee break. Hey! Do whatever works.

I believe it is a bit underestimated to recognise impediments at an early stage, and the moment you find it, go and talk to the right people. You will have this conversation one way or another, but the earlier it takes place, the less stress and pressure it would take.

There is a very interesting video from Jim Benson (creator of the Personal Kanban) about problems with the meetings we have at work and how to fix them. There is also part regarding dealing with issues mentioned above.

4. Estimates

It is always good to know how much effort is needed to implement a solution. And how long would it take to deliver it. There are tons of articles about estimating, so I will not go into details. You can use Story Points, T-Shirt sizes, etc.

Estimating can also help you with forecasting the delivery date. Based on the team’s velocity you can say when the work would be finished. You may also take a more Kanban metrics based approach with Service Level Expectation (based on histogram including cycle / lead times) and/or Throughput.

There is one more reason why this part of the Refinement should be considered as valuable – it encourages discussion. This may lead to discovering potential impediments and finding out who can perform the tasks better and who may require more support.

More Lean and Kanban concepts

There are some Lean and Kanban concepts worth mentioning in regard to Definition of Ready.

Point of Commitment

This is a concept I heard about during KMP classes from Kanban University. It should support the creation of the acceptance criteria. You can say it is some form of a handshake between the business side and the team, where both sides commit.

The business side commits that this is what we really need (and sometimes it happens that there is a difference between what you want and what you actually need). They thought about it, considered it and they understood what would be delivered. The business side commits that they would not come the next day and say: “sorry guys, we need to change this all over again”.

On the other hand, the team commits to deliver the solution, with agreed quality, that fulfills the needs that the business side had stated, with forecasted delivery date, if necessary.

Where should this Point of Commitment be located? Definitely before the “to do” status on your board, before the Unit of Work is considered actionable.

Defer Commitment

This is the Lean Software Development rule number 4, created by Mary and Tom Poppendieck. I highly recommend to go deeper into all 7 rules described in their book “Implementing Lean Software Development”.

Defer Commitment means you should make irreversible decisions in the last safe, responsible moment. You may, of course, ask why?

First of all, we should not forget that software development takes place in an empirical process control environment. The Scrum Guide says:

“Empiricism asserts that knowledge comes from experience and making decisions based on what is observed”

The more we work on something, the more we learn and know about it. If we start our work too early, we may not have enough knowledge to deliver the highest value.

Another reason to wait till the last possible safe and responsible moment is Lean thinking. Let’s quote Scrum Guide 2020 one more time:

“Lean thinking reduces waste and focuses on the essentials”

The situation may change, and the requirements with it. So if we start the work too early, and some factors change, we may have to do the same work twice. And that would be a waste.

You can consider Sprint Planning as a good example of Defer Commitment, the last safe and responsible moment to make important decisions.

Summing it up

One last thought. Last but not least. Definition of Ready is very useful, provides and makes us pay attention to some sort of entry criteria before starting work. We should perceive DoR as a checklist, but certainly not as an ultimate one. It should not become an excuse not to start the work, when the circumstances are dire and there is an urgent need for action.

I hope that this article gives you something beneficial to think about. If you have any remarks, please share them in the comments below. Thank you for reading!