Don’t be a DoRk

Martijn Oost
3 min readAug 11, 2016

I actually don’t like the definition of ready. The concept where stories are only considered for planning if they comply with a certain set of predefined rules. We can’t have the same binary like checks as in the definition of done. So if we want to treat it like the DoD, then very little could be stated in it. We could maybe say something about story format and acceptance criteria. But do we really need a DoR for this?

DoR: The magic shield for evil stories

Also the message it communicates is far more dangerous then beneficial in my opinion. It’s a message of distrust. Quite obviously towards the product owner, but also towards the dev team. It’s as if teams need a special shield to fend off stories that are not ready. I would like to suggest dev teams don’t need any armour like this. That they be a respected self organising team of cross functional experts. That they can say: “No” or “let’s do a mock up!” or “we don’t feel this story so much, let’s talk a bit more” or whatever. We should not have to apply some DoR band aid to restore this power to them. Inversely it could lead to a story being forced upon them as soon as it complies with the DoR. After all the story is ready according to your DoR, so just do it. If for some reason the team abuses the natural privilege of a self organising team to reject stories, then this needs immediate attention of a coach and not some extra set of rules to make people behave responsibly.

Depends

Even for external dependencies I would like to suggest a less rigid approach. If an other team or vendor we depend upon committed they will be done, we could already start. We could work together. We could code against agreed interfaces. We could do a lot. We could also still say: “no” or “not yet” lots of times. But if we definitely are not allowed to do anything by some DoR unless the dependency is solved, I guess nothing will happen by definition.

Highest priority

We should avoid DoR like obstructions in the flow of early and continuous delivery of valuable software. We want to emphasise that we are a team, PO included. That we don’ t need some official definition for us to be able to work together. On the contrary, working together is what defines us.

Team d’or

Team DoR

So let me suggest another definition of ready, the definition of are you ready to be an agile team. Because I have seen teams that were not ready thrown into an agile way of working without proper coaching. The result often is that new rule books like the DoR are invented to counteract a lack of agility. Let’s try it in an agile way first. Use openness, respect and courage to solve the problems addressed by the definition of ready. Not easy, but a lot more agile.

--

--

Martijn Oost

Natural born Agilista, Lean product thinker, Chief Trouble Maker.