Difference Between Acceptance Criteria and Definition of Done
A difference between acceptance criteria and the definition of done can be a thin line. It confuses a lot of developers.
One doesn’t have to be an IT expert to see that these are similar. That is why we decided to make a few points about the definition of done and acceptance criteria.
To make that distinction more obvious, we will add examples of each.
But before we dive into each of them, let’s start from the end. Let’s see why exactly two of them are confusing.
Similarities of the acceptance criteria and definition of done
Acceptance criteria and definition of done are methods you use at the end of your tasks or project. To be helpful, they should have some same characteristics:
- The team should agree about them
- The team should update them after discovering new learnings
- Possible to test
- Clear to everyone
- Concise
- Important for estimating the size of each task
The key difference between acceptance criteria and definition of done
The key difference between the acceptance criteria and the definition of done is what do they cover. While acceptance criteria cover functional requirements, the definition of done contains both functional and non-functional requirements.
Acceptable criteria are made for the user story and throughout the project. We make AC while doing referring tasks and before starting the sprint. In a formal Scrum definition, unique acceptance criteria for each feature or user story aren’t necessary.
Definition of done is set of user stories and accompanying activities such as documentation. DoD defines when the outcome is considered as done.
The goal of the sprint is to reach the definition of done. Consequently, all team members should understand it. Clarity of definition of done makes the planning of what user stories the team should work on.
What are the acceptance criteria?
Acceptance criteria are a set of conditions under which a user story should be created. It determines whether the user story met the goal of functionality. It is the list of functional and precise details that a user story should contain.
The purposes of acceptance criteria are:
- Explain what should the team create before the beginning of the sprint
- Bring clarity of specific feature
- Use automated tests to verify tests
- Relate development team and product owner
An example of acceptance criteria is:
Button for refund not allowed 30 days after purchasing.
Refund not allowed under $10.
The linked account is checked to ensure the number of days is less than 30.
An example of this is the user story:
As a customer, I want to click on the course and see the button for a refund so that I can request a refund from there.
Acceptance criteria are a guideline for a specific user story. User stories are units of work that together make the whole project. When the project is divided into small packages of work, the focus is moved from the bigger picture. User stories answer the question of how will the team deliver the value.
How to make acceptance criteria
Many rules that stand for the user story, stand for acceptance criteria as well.
If you set the plan in advance, there is more time to understand the customer’s need. Sometimes it is a good idea to make acceptance criteria for backlog for two sprints. That won’t require much time and will help the team to plan the technical process.
Too narrow acceptance criteria don’t leave developers space to maneuver. Keep in mind that acceptance criteria are not a decision but intent. On the contrary, too broad acceptance criteria don’t outline the scope of work.
Communication with stakeholders ensures the progress is going in the right direction. Further, to make it achievable, you consider it as a reasonable minimum amount of functionality that you can provide. Make sure that the feature could be tested. That is why acceptance criteria should be clear and concrete.
What to avoid in acceptance criteria
Writing what don’t want usually doesn’t specify what you want in the user story. Replace description with “don’t” into “do”. That goes for both user story and acceptance criteria.
USER STORY
Don’t: As a user, I don’t want to have to enter my payment method every time I want to request a refund.
Do: As a user, I want my payment method to be saved and automatically suggested so that I can easily choose it.
ACCEPTANCE CRITERIA:
Don’t: The system must not fail.
Do: The system should have an availability of no less than 90%.
When you are using passive voice, you are omitting the subject. Indication of a subject should be clear to know who should be able to perform the action. Passive voice in acceptance criteria also makes it difficult to test it.
USER STORY
Don’t: As a user, I want buttons for the refund to be shown.
Do: As a user, I want to be able to click the courses and then see the refund button.
ACCEPTANCE CRITERIA:
Don’t: The identification of purchased courses should be confirmed.
Do: The Accounting_System should confirm the Customer_Courses.
One more rule to write AC is to avoid writing pronouns. Undefined pronouns might cause ambiguity because it might be confusing what item are they referring to in other requirements.
This is even more important in tools that place acceptance criteria as separate items. One of the tools like that is Jira. This approach in Jira increases the possibility of bad organization and eventually losing the information. To help it, use nouns instead of pronouns to make AC more clear.
Definition of Ready (DoR)
To define the Definition of Done, you need to know inputs. In other words, you need to know what requirements you need to have to even start the sprint. This is how we come to the Definition of Ready (DoR).
Definition of ready stands for conditions that need to be done to start a user story or sprint. Like the DoD, it contains both functional and non-functional criteria. That is a checklist of things to do before adding a story in a sprint. In other words, the definition of ready stands for “if something is good to begin”.
An example of the definition of ready:
Enable button for signing up for the course.
Visible list of courses.
System check that the customer paid for the course.
Definition of ready can be useful in many parts of project management. Therefore, we can write it separately for each user story and each sprint. Here, the sprint definition of ready includes definitions of ready for all stories in the sprint. Here is how these two differ:
Definition of Ready for a user story:
- Acceptance criteria are defined
- Stakeholders are defined
- Sizes of user stories are suitable for the team
- Tasks are connected to user experience
- It is possible to have a preview of the story
Definition of Ready for a sprint:
- All team members have calculated their individual capacity for the sprint
What is the definition of done?
According to Scrum.org, the definition of done is a formal description of the state of the increment when it meets the quality measures required for the product. It is on a higher level than user stories. DoD includes functional and non-functional requirements. It explains what the should outcome look like and not how to reach it.
Definition of Done should build understanding within the team about the value and completeness of the project. After finishing the sprint, it gives a checklist for finishing them. At the end of the Sprint, the definition of done ensures the quality of the increment.
How to make definition of done
There is a lot of benefits of having a definition of done. Some of them are accurate estimates, explicit handovers, and clear responsibilities. However, just having it is not enough. Definition of done should be useful and written well. There are some steps for creating a successful DoD.
The whole team should decide what would they set as the definition of done. It should be understandable and achievable. The most important is to define it in a way that requires reasonable time. There is no sense of definition something that is impossible to do or it takes too much effort.
It should be possible to implement that part with clear consistency. The golden rule is that code works by itself and doesn’t break anything else.
Not to lose the track of specific project elements and their definition of done, it is good practice to always mark it. Otherwise, you could lose the track of which parts met the definition of done and which didn’t. Ensure that this practice applies to every feature within the sprint.
DoD grows with the product. As the product becomes more advanced, the definition of done is changing. Many tools however don’t provide solutions for manually taking in upgrades. On the contrary, JadeALM provides synchronizing updates of changes wherever your information is.
Conclusion
Both definitions of done and acceptance criteria are important for every project. To write them efficiently and understandable, one should have good project management skills. We hope this article was helpful and give you more insights on how to write them successfully.
Please don’t hesitate to get in touch if you would like to discuss the topic more.
