The waste of the Definition of Done and Definition of Ready (…when not actively used in your daily work)

I guess your are already using a Definition of Ready (DOR) and a Definition of Done (DOD)?
(If not – there are some hints at the end of this post 😉

Nicely printed DOD/DORs hanging on walls or hidden in Wiki pages – but not really used in your process are waste.

You can easily check it in your environment by asking the developers what’s in the DOD/DOR and how they really use it in their daily work. No answer or shrugging … bad sign.

This post is about ways to embed both important artifacts in your daily work.

Your vital Definition of Ready

As that definition is about story readiness it’s important to use it for story preparation and in pulling events. I highly recommend having an easy transportable, lightweight format that everyone can use in necessary meetings (see the picture about a possible format later on).

I use it in backlog grooming sessions. Together with the product owner we actively embed the DOR to check for every story if the story is already in a shape that the team can pull this story. We use it as a checklist – every point needs to be matched. Missing points are considered as homework for the product owner.

Next point of usage is in the sprint planning, when stories get finally pulled by the team. A final check if all DOR criteria are met and it ensures a high quality of input (if the DOR is well formed and has explicitly stated story quality criteria).

As soon as points are missing or not longer necessary it’s important to refine the DOR. Avoid erosion right from the start, otherwise it becomes blurry and more and more useless. I suggest to remove DORs that are not really used with every story as it’s just a false information radiator (leading to misleading assumptions about your process).

Who should finally push for using it? In my opinion the product owner (and the team remembering her/him).

And your useful Definition of Done

As the gatekeeper for accepting stories to be done it’s essential to have a living and really used DOD too. Like the DOR – make it easy usable. It’s not a catalog with 100 entries, it’s an artifact that covers the major criteria for a story to be done.

The first point of usage is the sprint planning. I recommend to check for every story that you forecast to deliver in a sprint/iteration that you check if you can really deliver it. Clarify for every point on your DOD that you actually can fulfill the given criteria. Recognizing mismatches short before a story is “nearly” finished is too late and really not necessary. As agile coach I remind the team in the beginning to use it actively – e.g. by asking the necessary questions using the DOD. By example the team can learn and will start following this practice.

Next point is the story review and acceptance by the team and product owner. Again use it as a checklist and show that every point is done.

Refine if your discover new points or not longer necessary parts.

Who should finally push for using it? The team (and the product owner remembering the team).

A handy format

I use an printed version (A5), laminated. It’s created for every team member, including the product owner and me. This way we can take it to every meeting easily, don’t need additional technical equipment. It’s a little more effort to create new ones – but affordable.

We combine it with the working agreements and team’s goal – and voila – it’s an active component in every meeting.