The terms "Acceptance Criteria" (or AC) and "Definition of Done" (or DoD) tend to be used interchangeably in the Agile community. Remember from my anatomy of a user story that you need to have a "how" included as part of your story. The AC and DoD are two ways of signaling to a developer that the work is "done." However, I see a distinct difference in these two concepts that I'd like to outline here.

Acceptance Criteria

Each user story is basically asking a developer to build out a specific bit of functionality or behavior. However, it's so easy to read a simple description of the desired feature and build out something that the requester never intended (by going too far or not far enough).

Acceptance criteria clearly outlines how the developer (or anyone reading the story) will know when the feature has been built to the desired level of completeness.

Here's a quick and easy example: We have a user story that is asking to build out a registration function for a website. The AC can be "A user can register a username and password that will allow them to log back into the website."

Simply put, the acceptance criteria tells us when the feature does what it is supposed to do...nothing more and nothing less.

Definition of Done

A good definition of done, on the other hand, gives a quick checklist, if you will, for the developer to know what they need to do in order to push their changes to the production environment. Maybe your team requires 100% test coverage before a change is allowed to be merged. Or maybe you want to specify that all integration tests are passed before the story can be considered "done."

Remember, a good user story should be independent. This DoD is a great way to ensure that stories can stand on their own, without dependency on another story. If DoD is complete, there is no reason (other than release schedule or choice) that the story can't be released on its own. The requirements may vary story-to-story or they may be static requirements that your team has agreed to for the entire project.

Do I Need Both?

I would argue that a user story is not fully complete without acceptance criteria AND definition of done. Now, that doesn't mean that you need a full DoD on each and every user story. If your team has defined a complete set of definition of done that is required for each and every story, having that posted on the team wall or somewhere else visible could be okay. The important thing here is that the person implementing the user story knows when to stop (or keep going).

This is just me sharing a frustration of mine. A professional pet peeve, if you will.

A few years ago, I went to a 3 day course which was described as an Agile Boot Camp. Since the company I was with at that time was in the infant stages of an Agile transformation strategy, this seemed like a great course for the project management team (all 3 of us).

The boot camp was full of great information and really got us pumped about what we were about to do. We spent an entire day talking about sprint ceremonies and how to use them properly. We discussed user stories and their relationship to epics, features, et cetera.

The class was awesome, but there was one major problem which I didn't really notice at the time....The class wasn't an Agile boot camp; It was a Scrum Boot Camp.

Agile is so much more than just Scrum. It's so much more than Kanban or XP or SAFe.

Agile is the why. The framework (such as Scrum or XP) is the how.

Just the other day, Mike Cottmeyer wrote a really great post about why frameworks and methodologies don't matter. If someone asks you to describe Agile and you give them an overview of Scrum, you're really short-changing them by giving such a limiting view of the Agile Manifesto, which is the set of guiding principles for Agile.

Agile is a mindset and a way of thinking. The Agile values can certainly be implemented through the use of a framework like Scrum, but Scrum is not Agile!

If you were in an elevator with a colleague and they asked you, "What is Agile?" How would you explain Agile to them in 1 or 2 sentences? Leave me a comment with your "elevator pitch."

I went to a Meetup recently of local Agile folks in the Atlanta area. We intended to discuss epic slicing and acceptance criteria.

And we did discuss those things...for a bit.

Then, as these things usually do, the discussion evolved into an entirely different topic. When a group of Agile enthusiasts get together, the topic of conversation always seem to evolve into the same familiar conversation.

Yeah, but what do you do when your Product Owner refuses to.....

What do you do when one developer won't.... 

Our QA team can't...

 Here's the thing:

Agile can solve your software development process problems. It cannot solve your people problems.

Pretty harsh, I know. But, you're asking how a methodology...a mindset...can solve problems that aren't caused by how you're doing the work, but rather they are caused by the unprofessional and demeaning behavior of individuals within your organization.

In order for an Agile transformation to take place within your organization, the organization has to change. It can't just be the development team or the project management team. The entire organization, from the top down, has to embrace the Agile mindset and allow it to happen.

People have to be willing to commit.

They have to be willing to define that minimum viable product and drop the Veruca Salt (Don't care how...I want it now) attitude that has been driving software development for far too long.

Management needs to be willing to let go of the reins a bit and let the people building the products make the necessary decisions to get the product built right, built quickly and shipped. You can't possibly expect a team to deliver quickly if every decision requires eight level of executive approval before anything can be implemented.

The organization has to restructure in a way that a product owner can be available to the team any time they have questions or need guidance. That product owner needs to be empowered to make decisions and prioritize the work when the need arises (see the point above).

Agile is not magic. Scrum Masters are not wizards. You can't just decide to "be Agile" and expect everything to be perfect. It takes commitment and work (LOTS of work) to shift the paradigm within an organization so that Agile can be allowed to take hold.