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
Pre-assigning Work to Team Members (Agile Transformation Pain Point #14)
Rachael WilterdinkRachael Wilterdink  |  
Dec 13, 2018
This pain point is something you definitely don’t want to do. Agile and Scrum teams are meant to be self-organizing. They should volunteer to pick up assignments, not be assigned. Development team members are volunteering to do stories, and they might want to learn something new &ndash...
Blog Article
Taking on Too Much Work in a Sprint (Agile Transformation Pain Point #13)
Rachael WilterdinkRachael Wilterdink  |  
Dec 06, 2018
Some teams are super ambitious, and they just think they can climb a whole mountain in a single Sprint, but the whole goal with agile is to maintain a sustainable pace. Take on only what you really think you can get done within your Sprint. Don't overestimate your velocity, and don't...
Blog Article
Diagramming & Modelling Tips for Business Analysts
Kurt WondraKurt Wondra  |  
Nov 20, 2018
Among the many responsibilities of Business Analysts, including Backlog Management and Communicating and Collaborating with our teams, the skill of diagramming and modelling is one which seems to be more taboo than mainstream. Have you ever wondered why that is?   One observation I&rsquo...
Blog Article
Forgetting to Have the "Conversation" (Agile Transformation Pain Point #11)
Rachael WilterdinkRachael Wilterdink  |  
Nov 15, 2018
You may have heard the three C's of agile: the card, the conversation, and the confirmation. Many people will have the card: they'll write the story, but they'll forget about the other parts. They'll just write it in a silo and not get any feedback. They won’t actually...
Blog Article
Struggles with Story Writing (Agile Transformation Pain Point #10)
Rachael WilterdinkRachael Wilterdink  |  
Nov 08, 2018
Story Writing struggles are so common and impactful that we offer a half-day training workshop on it for organizations.   Avoid technical stories Many Product Owners don't have a lot of experience writing requirements, and if you're a BA like I am coming from a waterfall world...