Mike Lyons explains how agile teams use Definition of Ready and Definition of Done as checklists to control quality. DoR ensures stories are ready before work starts: INVEST criteria, wireframes, known dependencies. DoD marks true completion: peer review, passing tests, documentation, no new technical debt.
On traditional projects, we have things called phase gates. Now historically, phase gates exist to help you not pass on bad quality or bad investment decisions from one phase to another. So say, for example, within the design phase on a traditional project, we design the product, we get all the architecture plans and we create the visio diagrams and we design. And we've invested time and money, sure, but we haven't built anything yet. And the idea was that there could be an inflection point, if you will, between that phase and the next phase. And there's some logic there. Phase gates can help you not make bad investment decisions. What the data suggested over time, and my personal experience has been with phase gates, is that they don't actually prevent you from making bad decisions. In fact, they gave the illusion of control, which without actually doing it. There's a book Harley Davidson product owner wrote called the Lean Machine. And in that book there was a quote in there that talks about how there's no correlation between phase gates and good product delivery. You might be asking yourself, hey, lions, like, what are you talking about phase gates for? This whole lesson is about definition of ready and definition of done. I don't want you to start thinking about definition of ready and definition of done as a phase gate. They're not. They're more associated with working agreements and how the team. Team's going to agree that a story is ready and agree that a story is done. Then they are a heaven forbid committee. Like, they're not that. Okay, so what are they? All right, definition already. Definition already is a list, an agreed upon set of guiding principles that stories will meet before they're ready to be worked on by the team. These definition of ready statements, you'll come up with those between your product owner, Scrum Master and the team members, and we'll agree to those things together. Definition of ready actually also gives us the ability to sort of push back to work sneaking into our sprint. And it happens once we get committed and get going, people will say, oh, can you just add, you know, can you just do. So definition ready is sort of that, you know, protection against work sneaking in. So let's look at some definition of ready examples. The team understands the story, the story meets the invest mnemonic. Wireframes or mockups are available, the dependencies are known, acceptance criteria is identified, and the team understands how they might demo this story. So definition of ready, very important. I want your teams to have definition of ready. I don't want them to slow you down, but I do want there to be some agreement that Says, okay, this story, you know, passes the sniff test. Let's bring it in. So just like definition of ready, we have definition of done. If definition of ready is like, how will we know we're ready? Definition of done is how will we know we're done? Definition of done gives us a visible list of all the things that stories need to meet before we'll, we'll call them done. I was working with one team and I remember at the end of one of our early sprints and I said, okay, so is that done? And Fred, one of our developers, he said, yeah, it's done. I said, well Fred, did you get the documentation done for that, for that API? Is our website updated? And he said, well, it's not done done. That was our joke. That one of the jokes. That was our joke as a team. Well, Mike, it's not done done. They would say so. Definition of done helps us get to done done, unlike acceptance criteria, which within a user story is unique to that user story, helps us know when, how to test it, when we'll be done developing it. Definition of done applies to all stories. So just quick point of clarification, try not to get those two things confused with each other. Definition of done applies to all stories. So what are some examples of definition of done? Let's take a look at a few here. The story we're working on has been peer reviewed. Now, peer reviewed just means that we've had another set of eyes on it. It's not just the developer or the tester or the person that created it. Someone else has looked at peer reviewed that story. All of our acceptance tests have passed. Our regression tests have passed. We passed our user acceptance test. Documentation is completed. We have not increased our technical debt. Look, it's important for you and your team to, to know, do we mean done is in production? This is a big one. I meet with teams all the time and done is, you know, it's in a lower level environment. Done is, it's being tested. And that's fine as long as we agree that's the definition of done. I will remind teams, however, that software that's not in production is not of value. Yeah, that might be hard to hear, but it's actually a liability. So does done mean software in production or software potentially releasable software in a lower level staging environment? You decide. My point is understand what definition of done is as a team and don't turn it into some committee that has to check off a bunch of boxes. Just make it part of your regular flow at the team level. Definition ready? Definition of done. Two things you want to have on your team.
