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.
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.
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).
0 comments :
Post a Comment