Definition of Ready is Evil
So you think you need to implement a Definition of Ready, or someone else thinks so and is telling you to do it. Don’t. At least not right away. Why do you need a Definition of Ready? Have you tried any other ways of solving those problems?
The Definition of Ready is a limitation on Agility. There is no argument against this. In an ideal Agile environment, a team should be able to start with simply an idea and end with an iteration on that idea that advances either the user’s value from the product or the team’s knowledge.
If the only reason Definition of Ready has come up is because it’s a “best practice” let me stop you right there. There truly is no such thing as a best practice that works everywhere. There are good ideas that work in certain situations. This isn’t a practice that should be employed everywhere.
If there are types of impediments that are frequently slowing down the team, you might benefit from a Definition of Ready. But, have you discussed these impediments in team retrospectives? If the team cannot remove them or influence others to remove them, are there other Agilists at a higher level that can help? Is this something that your leadership can change? If you’ve tried all of that and still face constant impediments in the short term, then a Definition of Ready can help. Your team will be more productive working on the highest value work that is ready for them. It’ll also be less stressful (since they’re no longer responsible for getting things done that are out of their control) which should result in happier teams.
Your Definition of Ready should only contain the items that affect your team. Don’t start with someone else’s. Keep it as short as possible. Write it in simple unambiguous language. A good Definition of Ready, like a good Definition of Done, is something that everyone on the team understands and can readily recall. Anyone on the team should be able to look at some new work and explain how it doesn’t meet the Definition of Ready. Make it available and review it with anyone that is a source of work for the team. Great partners will internalize it themselves and wait until work is ready before bringing it to the team.
Don’t stop there. Do not write a Definition of Ready, bind it with red tape, place it on a pedestal and be content with it. It is evil. You and your leadership should despise everything in it. It is leadership’s duty to one-by-one remove each and every condition from it until the team is left without a Definition of Ready. When this has happened you’ll be more Agile than before and the work will be better for everyone involved, including the people using your product.
About the Author | Mike Brewer
Mike is an Agile Coach that believes in the ability to create better outcomes for customers, workers, and companies through the values and principles of Agile. You can connect with him on LinkedIn.
