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
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
Let’s learn together?! Can recommend more ways to actively use the DOD/DOR? I’m looking forward for your great ideas.
Leave a Reply