I used to be like you. I was that Scrum Master who thought that a Definition of Ready was a nice add-on to Scrum for starting teams. Teams struggling with clarity in their Backlog Items, teams constantly not making their Sprint Goals and being completely unpredictable in delivering the Sprint Backlog, teams working under heavy constraints from laws & regulations, etc. In all these cases, what is the harm in a checklist of stuff we need to do before we can plan and forecast it as part of the Sprint Backlog and Sprint Goal? The only reason not to use it was simply that experienced teams don’t really need it, but what could be the harm in using it as a crutch for starting teams?
These days, I’ve come to realize that this way of thinking poses a huge danger for delivering value with Scrum. And I believe I’ve come to understand why the Definition of Ready is not in the Scrum Guide, while the Definition of Done is. My journey to come to this insight goes all the way back to the origins of Scrum; the Toyota Way or Toyota Production System. In engaging with Lean thinking, the way Lean-Agile mindset is framed in SAFe, in discussions and observations with teams, clients and colleagues…
So then, what did I realize? What is the reason I believe we should NEVER use a Definition of Ready? Why is this such a bad idea that you should really steer clear of it, even though it seems to be helpful? At least for new teams, teams struggling with readiness of their Backlog Items, Teams struggling with making reliable forecasts needed to build trust, deliver customer value and collect the right feedback to fuel their empirical process?
Flow. The reason we should steer clear of Definition of Ready is that it has the potential to create a barrier for flow. I’ve seen the Definition of Ready lead to backlogs clogging up with non-ready high ordered items, leading to a loss in transparency for the Scrum Team & Stakeholders. I’ve seen teams becoming frustrated because the Definition of Ready prevented them from ‘just’ start working on items. Even while they knew from experience that everything that is needed to get to “Done” always gets put in place before the end of Sprint. I’ve heard scary stories about ‘Ready Teams’ and two-phase Scrum, all the way up to Water-Scrum-Fall. And yes, with a Scrum Master who is awake, the continuous improvement process should surface these problems and more importantly fix them through retrospectives and solved impediments. But why set yourself up for failure? Why add stuff to the framework that you KNOW creates these problems. Or even worse, introduce a practice that gets embedded in the organizations’ way of working until no-one remembers the exact reason it’s there, but no-one dares to suggest to remove this toxic practice ‘because this is just the way it has always been’. So please. Do yourself a favour. STOP IT. Next time you hear someone mention the Definition of Ready, ask them what problem they hope to solve. Help them solve the problem with a practice that actually helps. Like the practice of ‘Just Talk’. And by all means have a checklist of stuff that previously caused failure, to help the practice of ‘just talking’ in refinement and sprint planning. But NEVER, EVER, let the checklist become an artefact that can be turned into a barrier. Don’t formalize the checklist into a tool or process where items can only be pulled by the Development Team after reaching a certain state or filling out certain information. You will be contributing to killing one of the principles that the Scrum Framework was built on, and you will be setting the team up for failure. This WILL be on you.
If you want to enable flow, don’t use a Definition of Ready.