In one of our earlier posts I discussed the elements and benefits of “Definition of Ready”. However it’s quite common to see totally opposite views of purists as they believe that Definition of Ready is not required at all.
I agree to their views to some extent if it’s all about collocated teams supported by dedicated product owner in the same time zone.
However, distributed Agile is a different beast altogether. It’s quite common in India to work with customers in opposite time-zones. Distributed communication essentially is an overhead. So the clarification which you receive in minutes face-to-face with collocated product-owner may require multiple iterations of distributed communication. Multiple iterations essentially mean multiple days.
So a READY user-story which could be finished in 2 hours now takes days to complete because of to and fro communication between distributed team-members to resolve unresolved queries.
Definition of Ready in such cases helps in bringing clarity and in keeping team members and product owner on the same page. Any absence of clarity essentially complicates the cycle time and throughput of a sprint.
More on Backlog Refinement, Story Points and Agile Estimation
This post is a part of a blog post series on story points and agile estimation. To read rest of the posts on the subject, please navigate to All About Story Points and Agile Estimation Series.
Somehow I feel this “Definition of Ready” is just a bit of process complexity to catch or cover up for the story backlog not getting enough attention before sprint planning, or indeed to somehow bypass or diminish the conversations that should happen during sprint planning? When a team commits to a story, they should really have driven the ambiguity out of it with the PO already to enable them to get on with it. (or at least 9 times out of 10)
If there are “days of [..] unresolved queries” then the user story should never have made it into the sprint in the first place.
If not understood, I could see this “Definition of Ready” turning into a mini specification for each user story (if its at a level to be properly useful) but that detail should be in the acceptance criteria, or if it is just sweeping broad set of statements then I am not really sure what it adds at all?
I know Scrum needs to adapt, but I’m not sure what real “value” this adds to the process even in distributed environments.