Back to List

Not Having a Definition of "Done" or "Ready" (Agile Transformation Pain Point #12)

Rachael Wilterdink Rachael Wilterdink  |  
Nov 29, 2018
Most people who are familiar with agile are familiar with the concept of definition of Done.

This is something that the team should create when they are first formed, and they should continually be inspecting and adapting that at each of their retrospectives. They can update that definition of Done if they're finding it doesn't work for them, but they need to have one because everybody has a different idea of what Done means.
not having a definition of done or ready

Definition of “Ready”

Ready is probably unfamiliar to many, but it is about your user stories’ acceptance criteria. Are they complete? Do they have all the necessary information so developers can take that story and acceptance criteria and get to Done? Ready is really about the stories themselves; Done is about the actual delivery and development of the work.

Definition of “Done”

When I talk about having a definition of Done, you want to make sure your stories have sufficient detail. They need to be able to be developed. Without all the detail, you're going to have questions coming back to you, and you want to get those questions answered up front so you're not slowing down your development team.

Also, if you are working on a team and you have not truly completed the stories to the group's shared understanding of the definition of Done, don't let that story be demonstrated or shown. It's not really done until it's met all the criteria.

Checklist before take-off

Think of Ready and Done as a checklist you would go through and check off to make sure everything is complete for it to be done –much like what an airline pilot does before they can take off. There's no such thing as “kind of done”, “sort of done”, “almost done”, or “done done”. It's either Done or it's Not Done.

Get the free eBook

This is the twelfth of 20 blogs on 20 Agile Transformation Pain Points (and how to avoid or manage them). To read them all right now, download our free eBook.
agile transformation pain points ebook


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Blog Article
Skipping Inspection and Adaptation (Agile Transformation Pain Point #20)
Rachael WilterdinkRachael Wilterdink  |  
Jan 31, 2019
Inspecting and adapting is one of the key parts of agile and Scrum. But over time, teams start to feel bored as if every session is the same.   If it does become boring, make sure you switch it up to keep it fresh. The Fun Retrospectives website has lots of ideas. Don’t skip this...
Jan 29, 2019
Jen Kalz is Featured on Mastering Business Analysis Podcast

We are excited to announce that Jen Kalz, Managing Consultant, is a featured guest on today's Mastering Business Analysis Podcast. Jen has known Dave Saboe, the man behind the Mastering Business Analysis site and podcast, for the last several years. She and Dave often speak at the same...
Blog Article
Distributed Global Challenges (Agile Transformation Pain Point #19)
Rachael WilterdinkRachael Wilterdink  |  
Jan 24, 2019
So far, I've been primarily discussing co-located teams, which is ideally better. However, this is the real world, and it's a global economy – most people don't have the luxury of being co-located.   If you have a team with dispersed team members, set up your working...
Blog Article
Accruing Technical Debt (Agile Transformation Pain Point #18)
Rachael WilterdinkRachael Wilterdink  |  
Jan 17, 2019
Everyone who works in technology probably knows that you already have a big pile of technical debt. The problem is that you are going to have to eventually pay that bill, and some of it is risky.     Dig out a little every Sprint You really need to be careful about technical...
Blog Article
Focusing On Projects Rather Than Products (Agile Transformation Pain Point #17)
Rachael WilterdinkRachael Wilterdink  |  
Jan 10, 2019
This is a difficult transition for waterfall companies to wrap their heads around. It's a big mindset shift that needs to happen to be truly successful. I'm not saying that you can't have an agile Scrum team that works on projects with a distinct beginning and end. That might be a...