Have you come across teams struggling in iterations bombarded with surprises ? I have seen many times.
Teams and POs concentrate mostly on “Definition of Done” by keeping the end in mind, which is good. However, it is also important to evaluate the readiness before entering the iterations.
As we all know, Garbage in – Garbage Out, if the team starts Sprints/iterations with weak information, the output produced too would be of poor quality.
In one of the case studies, Team didn’t have the acceptance criteria for all the user stories. But they were convinced by the PO that, it would be detailed out during the iteration. The team signed up and incidentally, things didn’t go as per the plan. The team ended up building a few stories with incomplete features.
Imagine having a robust checklist which is used as the gateway into a Sprint. Noting is allowed into the Sprint fort without getting clearance from this gateway. This gateway is nothing but Definition of Ready(DoR) Checklist.
The Definition of Ready checklist will have the list of items that need to be in place before stepping into the iteration.
Some examples include,
* Clearly defined User stories are one of the key items to be ready before the iteration planning meeting
* A healthy backlog with enough stories for atleast 2 iterations
* Healthy Dev and Test environments
* Availability of team, etc
A few points to remember
* The DoR checklist is a living document and should be kept upto date with the learning from each iteration.
* Scrum Master could own this document.
* The list should have the inputs from not only the Scrum Team but from Product Owner(s) ,Scrum Master, Business Analyst and other stake holders.
I have created a DoR template with typical items needed to kick start using it. This is not an exhaustive list, but gives you a feel of DoR items. Feel free to download the PDF version of the template from here. This is free to use as a starting point for building DOR checklist.