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.
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.