Recently I read a blog post by Mike Cohn in which he wrote a comment where he says that he is not a big fan of the Definition of Ready(known as DoR from here on out). What in sam hill?? In fact his exact comments were...
Mike Cohn says Definition of Ready is antietical to agile
“But I’m not a fan of definitions of ready in general and certainly not one like that. Here’s why: Any time you put a gate in place that says “nothing can go past until until *all of x* is done” you have created a sequential process.
That is, generally, very antithetical to agile.”
…so as you can image this made me think and think and think. Is it possible that what I have been doing all this time is antiethical to agile?? How could this be. So I decided to do a bit more research to see if my thinking had been off all along.
Scum Inc’s Definition of Ready states the obvious
I first found Scrum Inc’s definition of Definition of Ready (pun intended) …. “Having a Definition of Ready means that stories must be immediately actionable. The Team must be able to determine what needs to be done and the amount of work required to complete the User Story or PBI. The Team must understand the “done” criteria and what tests will be performed to demonstrate that the story is complete. “Ready” stories should be clear, concise, and most importantly, actionable.”
So while I agree that all of these things need to be there I don’t agree that this is your typical Definition of Ready where teams state that the DoR should have things such has “must have all acceptance criteria” or “mocks up must be complete and approved”. The items mentioned by Scrum Inc are very general and simply indicate that a Story must be clear, concise, understood and actionable. Well for me and many other seasoned practitioners these all go without saying (or writing) in this case.
Roman Pichler’s explanation of Definition of Ready better but still generic
Next I came upon an article by Roman Pichler titled The Definition of Ready. In his article he states that a story must be clear, testable and feasible. All three are good points as we must be able to understand, test and complete the story. However this also seems like the canned explanation of Definition of Ready and are also things that I believe all stories must have in order for us to consider them for breakdown during Sprint Planning.
So what’s up with Mike Cohns opinion of Definition of Ready?
First let me understand what Mike is saying. He is saying that in agile we should not have stage gates and checkpoints that prevent the team from doing and getting things done. After all agile is all about start doing and building and things will become more clear as we go along. This is very true and correct and if we do end of have checkpoints that prevent us from doing withouth some sort of precursor then Mike is right, we might as well call it a hybrid scum-waterfall or scrumerfall or waterrum (is this an actual alcoholic beverage??).
But bad things can happen if I work on stories not ready to be started
So that begs the next question which is if I don’t have a Definition Of Ready then how do I deal with all the problems that may occur? For example, when teams estimate and add stories to the Sprint Backlog that are not ready (i.e. mock up not created and approved) then this sometimes leads to:
- Stories not being completed by the end of the sprint
- Stories being completed but taking twice as long as estimates
- Tons of additional tasks being added to stories during the sprint (some dealing only with unnecessary rework)
- Stories being completed that are rejected by Product Owner
How do we handle the issues that occur when we start stories without a Deifnition of Ready
The simple answer is: You don’t
The detailed answer is: You need to come up with a Definition of Ready that is not like the one Mike Cohn is thinking of which restricts the starting of stories with a stage-gate and come up with one that simply provides enough data/information to allow the team to get started.
When we create Definition’s of Ready that are very restrictive and require stories to have too many prerequisites (i.e. mock ups must be created and approved) then this creates the restrictive stage-gate that Mike Cohn says is against agile values. The goal should be to create a Definition of Ready that makes the story “ready enough”. The DoR should have requisites such as is the story detailed enough and if not then does it have enough acceptance criteria (note I did not say ALL acceptance criteria) to allow the team to understand it and begin development of it. If the details of the story emerge during the Sprint and allow the team to complete all of the story during the sprint then great. However if that does not happen for whatever reason (i.e. creative folks created a new persona) then the story could be broken down into multiple stories in collaboration with the PO and the team can still move forward. Remember that during a Sprint once the development team completes development for everyting they know about a story / acceptance criteria they can always switch over to another story in that same sprint plan and keep working if they are waiting for clarification. No need to develop something by taking a guess at what would be needed unless the PO agrees to that leap of faith. An example of a less restrictive DoR is:
- At least 1 acceptance critieria created
- If mock ups are required then at least 1 mock up available for view (even if not formally approved)
- Story is clear enough to be understood and broken down into at least 2 or more tasks with estimates
- Story traceable to source document (source document accessible to team)
- If story clarificataion received through someone not on Product Team then clarification is at least sent to PO (not waiting for approval)
Exceptions to the rule
Not I know and completely agree that having a loose DoR will lead to the following in some circumstances:
- Increase in cycle time
- Decrease in throughput
- Larger than needed WIP
- More stories not completed by the end of the Sprint
Therefore I have two caveats on when NOT to have a “let’s get started” DoR. The first is in environments where the PO is not readily available or does not have a Product Team that he/she depends on for clarification of requirements. When this is the case then the team will have difficulty getting the clarifications needed for emergent design.
Secondly, do not have a “let’s get started” DoR when you have shorter Sprint cycles (1 week) or when the team is not very mature with agile. With shorter sprint cycles it will be difficult to get the clarifications and design decisions needed in time. Additionally when the team is not experienced enough using an agile process then they will not be able to effectively “right size” the stories during sprint planning which will lead the the four bulleted issues above.
I surmise that all teams should have some semblence of a DoR however you must find a balance not to bloat your DoR to be so restrictive that stories must now pass through a stage-gate and not too loose so that stories are being started that do not have enough clarity and requirements for the team to complete them and get approval.