Frustrated With The Definition of Ready? Try a Dialogue of Ready

The Importance of Being Ready
Alright, folks, summer’s knocking on our doors, and you know what that means. We’re finally setting off on that exciting journey to an island full of coconut trees and hammocks! Escaping from the laundry pile and the towering work emails – a slice of paradise awaits. With just a day away from dashing to the airport, let’s not forget our past holiday hiccups. Being well-prepared makes all the difference between a smooth sailing trip and a stormy voyage. Interestingly, this concept of being ‘ready enough’ isn’t just applicable to our vacation plans; it’s also a crucial element in the professional world, particularly in Agile and Scrum practices. In this article, we will explore a lightweight approach called the ‘Dialogue of Ready,’ a technique designed to hit the readiness sweet spot, especially when your Defintion of Ready is weighing you down.
The Pre-Flight Checklist Analogy
To keep our heads cool and checklists ticked, we’ve got our trusty pre-flight routine down pat:
- Checking if the checked-in luggage isn’t heavier than a small elephant (50 lbs, to be exact).
- Making sure the carry-on luggage isn’t so bulky that it requires its own seat.
- Double-checking that carry-on liquids are within the allowed 3.4-ounce limit (we’ve all had that shampoo explosion, right?).
- And hey, remember to leave the nunchucks at home this time—sure, it’s a laughable memory, but let’s not give airport security a rerun.
- Charging the lifelines—your laptop and phone—to their max.
- Make sure essential IDs like your driver’s license and passport are tucked away safely.
Alright, bringing it back to the heart of the matter—readiness. Without it, we’re setting ourselves up for some serious bumps on the road. Think lost bags, missed flights, and maybe a rendezvous with security for forgetting that those nunchucks were still hanging out in your gym bag.
Defining Readiness in Scrum
Being ready isn’t just for your holiday vacation. It’s just as important in our work lives. Having the right information and resources can be the game-changer between smooth task completion and pulling out your hair. This is especially true in the Scrum framework, where we start and hope to finish work within a short timeframe—a ‘Sprint’. Being ready here is super important.
Many teams use something called a “Definition of Ready” or DoR. It’s like a checklist for a product backlog item (often a user story), and it needs to pass this test to be brought into a Sprint. If it doesn’t pass the test, it’s not ready—kinda like your oversized carry-on luggage. Even though the Scrum Guide doesn’t specifically mention a DoR, it does say that “Product Backlog items that can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.” That sounds like good common sense to me!
The Traditional Definition of Ready
Personally, I’m a fan of the DoR—it’s really handy, as long as you don’t turn it into an epic novel. For instance, my DoR is lightweight and usually looks something like this when using Scrum:
- The problem statement is clear
- No pesky dependencies are getting in the way.
- The Product Backlog Item is small enough to be completed in a Sprint
- Item has Acceptance Criteria that are clear and testable
This does not feel like big design upfront requirement specifications or waterfall to me.
Criticisms of the Definition of Ready
Now, I’ve heard some folks grumbling about the DoR, even saying it’s evil and messes with our agility. But let’s be real. That only happens when people misuse it, turning it into a mammoth task of eliminating all uncertainties before a Sprint starts.
This usually happens in places where unfinished work is treated like a cardinal sin and where everyone’s obsessed with velocity as the primary metric. In these situations, teams will rationally want to have all the details ironed out before the Sprint. This isn’t the DoR’s fault—it’s how people use it. How we use our tools reflects our mindset and our work culture.
A Lighter Approach: The Dialogue of Ready
But let’s not forget that being underprepared is a disaster. We need to make sure we’re ‘ready enough.’ So here’s a friendly alternative I propose—the ‘Dialogue of Ready.’ It reduces the risk of falling into a ‘Big Design Up Front’ trap and increases our confidence that we’ve got enough info to get the ball rolling on a Sprint.
It’s simple and embraces the Agile values of collaboration. Here’s how it works:
- Take a product backlog item and ask the team, “Do we feel good about bringing this into Sprint Planning? We might still need to do some detective work, but can we complete it in a Sprint?”
- If the answer’s “Yes!”, then it’s ready.
- If it’s “No,” ask, “What do we need to get this ready enough?”.
- Refine accordingly based on the discussion.
The Benefits of Dialogue of Ready
Embracing the Dialogue of Ready approach can reinforce Agile values and principles, offering these exciting benefits:
- Promotes Team Collaboration – This approach gets the whole team talking versus just checking off boxes in a document, leading to a mutual understanding of each backlog item. Nothing like good ol’ communication to get everyone on the same page!
- Welcomes Change – Let’s face it; change is inevitable. So, why not make room for it? This method allows for tweaks and turns as you gather more info or when requirements do a little dance. Adaptability is key!
- Encourages Continuous Learning – Our method appreciates that learning is a part of the process, and some lessons come from just rolling up the sleeves and getting the job done.
- Focuses on Value – The Dialogue of Ready keeps our chats focused on delivering what matters most – customer value. And hey, the sooner we start, the sooner we deliver!
Personally, I’m all for the DoR as a ‘ready enough’ checklist – as long as it’s light and encourages conversations. But if your team’s been using it as an overstuffed suitcase, it might be time to switch lanes and take the ‘Dialogue of Ready’ for a spin instead.
Let’s not forget our tools should support agility, not impede it. They should enhance adaptability, spark creativity, and respect team empowerment.If the DoR feels like dragging weights rather than a launching pad, a change may be due. After all, staying agile means continually learning, adapting, and improving – now, isn’t that the essence of agility?
Ready To Learn More?
If you enjoyed this, you might love our Certified ScrumMaster course, Certified Scrum Product Owner, and Certified Agile Classrooms Teacher Courses. Check out our workshops; we make Scrum and Product management simple, practical, and fun!