A Definition of Ready is Critical to Predictable Delivery
Why do you need a definition of ready?
The more unknowns there are in the development process, the lower is the predictability. And while unknowns are inevitable in complex work, some of them can be avoided, especially those that originate from lack of clarity and poor communication about the intent.
What is definition of ready?
See, every backlog item that the team receives has some missing information. A part of this missing information is actually lost in transition from those who want something to be built to those who actually build it. The requestor of work may be assuming too much about the team’s knowledge of a particular backlog item, while the team actually needs more clarity. The other part comes from the fact that the requestor may make too many assumptions about the work itself and its customer value. And those assumptions may not be correct. So, we need a way to keep those assumptions in check and fill in the necessary gaps. A good tool to achieve this goal is the “definition of ready”. The definition of ready is the general criteria that your backlog items must satisfy and only if they do, they can be committed to work.
Here’s an exemplar definition of ready for software features for a specific team. The team and their stakeholders consider an item ready for execution when the following is true:
· The team has all their primary questions answered by the customer regarding the item
· The item has a meaningful customer or business outcome statement
· For all known dependencies, there is a general idea of how to handle them and there is availability of the dependent parties
· Stakeholders and the team are aligned on what’s more and what’s less important within the scope of this item
· There is a specific way to ensure that the item was successfully implemented
Of course, it can be a different list for a different company or even a different team within the same organization. And maybe a team that is working on a new rich-UI system would include something like “readiness of UX wireframes” to the list. Or a group that is working on important identity management solutions would have something like “consulted with cybersecurity architect” added to the definition of ready. And so on.
Two important questions
So, here’s the first question: What should be your definition of ready? What items should it contain. The best way to go about this is to develop one. And it would be great to do involving different people, like the requestors of work, team members, other involved subject-matter experts. Have them agree on it.
Second question: When should the definition of ready be applied to a backlog item? Well, clearly it has to happen before the work begins. Which leaves us with planning or, better yet, work refinement – a type of a session that precedes planning and actually exactly aims at establishing the readiness for the work items.
Alright, you tried to answer questions one and two? Great. That will help you determine your course of action in leveraging the definition of ready in your environment. Plan to do one or two concrete things in this regard.