Definition of Ready (to be a robot)


Robots are cool, but they don’t get to make important choices.

Most agilists are familiar with Definition of Done (DoD): a team works together with the Product Owner to agree on a set of criteria that they can all point to and say “a story is complete when this list is checked off”. DoD can get pretty elaborate, including automated testing, documentation, bug rates, and so on. Teams don’t always hit their DoD with every story, but it’s a shared goal and reduces debate over what “done” really means. The value of a Definition of Done seems pretty obvious.

Definition of Ready (DoR) is the natural companion to Definition of Done, but it’s used maybe a bit less often. It lists out all the characteristics a story should have before the team accepts it into the sprint. It’s most helpful when teams struggle in their collaboration with Product Owners, business analysts, UX specialists, or other dev-team-adjacent roles. It says, “look, we’re eager to make a firm commitment and get started on this work, but we can’t just wing it. We need good acceptance criteria, and need to have talked about the stories enough to feel like we know what you want and how long it might take. We expect some challenges and surprises, but there’s no reason to be totally unprepared.”

Again, the value of a good Definition of Ready seems apparent. But I recently saw a DoR that looked something like this:

  • Acceptance Criteria detailed enough to be the basis of a test plan.
  • All UI wireframes completed by the UX team.
  • All text content finalized and translated.
  • All input validations detailed and complete.
  • System designs complete and finalized by the architecture group.

… plus all the usual stuff about sizing, review with the Product Owner, and the INVEST story characteristics.  Seems good, right?  I thought so at first too.

So, What’s the Problem?

The team with this Definition of Ready had a few notable characteristics:

  • The Product Owner and adjuncts (BA, UX) struggled to get things ready in time even though they were clearly trying.
  • The team was quick to point to missing DoR items as a reason for problems getting stories done and done well. “Well, the error messages weren’t provided.”
  • There was an over-dependence on design “spike” work prior to the sprint, often by different people.
  • Team members often complained that the work was boring or cookie-cutter and that there was no room for creativity.

What if I paraphrased the team’s DoR like this: “Before we start to work on these stories, we want them to pass through a series of gates – Product Owner, UX team, and architecture team – so that everything is finalized and we can be 100% sure in advance we know exactly what to build”? Hmm, what’s that sound like? Starts with “W”, has “RF” in the middle, and ends with “L” … no, not “Winterfell”. Waterfall!

How Did This Happen?

The team certainly didn’t mean to ask the business to spell out their work for them to that degree. They were reacting to some common problems that spring up in teams, mostly around communication. This team was pretty disconnected from the customer and the product vision, and wasn’t getting involved in any of the brainstorming and back-and-forth debate about features and how they should work. In addition, the organization was under a lot of pressure to deliver a lot in a short time and was reluctant to give the development teams an open license to be creative; instead, people in various named roles were expected to provide 100% of the ideas in their space. Finally, communication during sprints was unreliable because of how busy everyone was with design for the next feature, conferences, customer surveys, meetings, and tons of other stuff.

In this environment, the team had been left in the lurch more than once. Three days left in the sprint, and no one to answer a question. Lots of “we actually meant this; can you squeeze in that change?” Bombshells, curve balls, the works. And despite all this, a real quickness to blame the team any time a sprint didn’t burn down 100%. They went into defensive mode and traded the joy of creativity for the certainty of detailed requirements.

The Fix

There’s no exact right amount of detail to demand before accepting a story into a sprint. We’ve all heard that a story is an invitation to a conversation. That conversation should certainly start before the sprint, in story sessions, backlog grooming, and high-level design white-boarding. But it absolutely must continue into the sprint as the team begins to grapple with the details and has early builds available in test environments. That means that the Product Owner needs to be available throughout the sprint, which is a basic Scrum rule that is often broken to varying degrees. It also means that the team should have more authority over technical decisions and should not need be overly reliant anyone outside the team to give them answers. Remember, an ideal Agile team has the skill set to deliver a feature on their own. They should make a plan to own the work themselves and pull in auxiliary resources as needed instead of waiting to be given a complete instruction manual. If those auxiliary contributors have daily, strong, and open communication with the team, the team can get comfortable with a bit more ambiguity going into a sprint. I feel strongly that this makes for a healthier, happier team that is able to really deliver the spirit of want the business wants, and more often than not surprise and delight the Product Owner with brilliant solutions to the business problems posed to them.

I’m not saying to throw out your Definition of Ready, if you have one. Just don’t let it be a substitute for continuous communication or for trusting your development teams to make some decisions in flight. And teams – don’t write all the creativity out of your job.

2 thoughts on “Definition of Ready (to be a robot)

  1. Christopher Curley

    There’s a notion called the “bureaucratization of the imagination” that comes up in the definition of ready — or if you’re in a fixed scope world, the WBS dictionary.

    Essentially, nothing we imagine can be realized with the purity of what we imagine it to be, because once we being to organize our thoughts given the systemic and normative constrains of organizations and individual networks, we end up having to make practical compromises.

    I’ve seen product owners struggle with this. The scrum team delivers something that meets the DoD but (implicitly or explicitly) doesn’t satisfy a DoR — even when it meets the DoR.

    Sometimes because the DoD/DoR was poorly expressed in planning, and the mistake was failing to collapse the sprint.

    Other times, notably, it was that the DoD was met (we did what we committed to do) and the DoR was met (what we did is the solution you need), but how the release met the solution failed to meet an unexpressed normative or aesthetic goal. That is, you said you were cold and a sweater of this size, weight and material would keep you warm and dry against the weather… which is what we did, but now you are complaining because you are not feeling fashionable.” Or, “we fed you the calories you needed with the right balance of protein, carb and fiber, but you didn’t care for the taste or texture.”

    Compared to the solution in the PO imagination and the solution implemented against testing, the work product leaves the PO unsatisfied despite satisfying the POs conditions.

    So, one of the tough things to tease out is “are you unsatisfied because we didn’t get the right outcomes for the DoR or did you get the outcome you needed just in a way that doesn’t delight you with it?”

    This is difficult conversation to have with the PO, especially if the PO has “had Agile imposed upon them unwillingly.” For the scrum master or coach, might be one of the most important conversations during a retro.

    I welcome — and really mean welcome — thoughts, challenges, disagreements, or insights that might spring from my comments here.?

  2. Bill Karnavas

    The flip side of this is that a conversation has to be open ended or at least flexible. You can’t say to your spouse that you are going to discuss what to have for dinner for 7 minutes then make it in 22 minutes. The developers, I’m guessing, were demanding 100% complete DOR because they were forced to make time estimates, and deliver on them, that were expected to be 100% accurate. That estimate is not an estimate. If you want the story to be a conversation, you have to accept that estimates are estimates, and their accuracy will evolve with the story.


Leave a Comment