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

I know there are a lot of templates out there for what a good user story should look like. I'm not going to go down that path, because honestly I don't care what words you use in your user story as long as you have all of the important information included. Here's what makes a good user story:

Who

In order to build out a piece of functionality with a certain degree of autonomy, I need to be able to make decisions about the little things. The best way to know what the right decision is in any given situation is to know who you're building the functionality for. A single piece of functionality can have many different uses based on the user, so knowing who the user is makes the decision-making process a lot simpler.

What

This one is a bit more obvious. The person looking at the user story needs to know what is being asked for. Now, this shouldn't be a super-specific thing like "red button on the top left corner" or anything, but it needs to give enough detail that I know what's being asked for.

Why

If you ask me, this is the most important part of a user story. Building out functionality is great, but I can go in a completely wrong direction if I don't understand the motivation behind the request. Not only that, but if I truly understand why you're asking for a particular piece of functionality, I may have ideas on how we can provide the value in a better way. That little bit of why can really open up a world of possibilities and discussions.

How

No, now how to implement the functionality requested. That's a major no-no. This how is really how do I know when I'm done? Each user story needs to include a definition of done and acceptance criteria, so that we know when the work is done. How do I know when I've gone far enough with the work and can say it's "done" to a satisfactory level?

So, there's the very basics of what information should be included in a well-written user story. You can write it in the "As a ..., I want ..., so that ...." format, or you can write it any other way you like, as long as this important information is included.