The sum of all stakeholders' expectations of a product is formulated as requirements. A requirement always describes a specific function or property of the product. Once all requirements have been implemented, the product is complete.
But how can we ensure that the requirements are formulated in such a way that the finished product actually meets the expectations of the stakeholders? What we need are high-quality requirements that contain all the necessary information for the people implementing them and do not allow for individual interpretation.
In software development in particular, requirements are often written in the form of user stories. Acceptance criteria also help us. They are defined specifically for a requirement and tell us when a requirement can be marked as complete. In other words, they specify our requirement.
It is recommended to name three to five acceptance criteria for each requirement. It is best to write them as a kind of checklist in short, bullet-point sentences below the requirement description. Once the requirement is complete, the checklist is reviewed. If not all items can be checked off, the requirement has not yet been fully implemented.
Please note: Acceptance criteria serve a different purpose than the Definition of Done. While the Definition of Done applies across the board to all requirements of a product, acceptance criteria always refer to a specific requirement. A requirement can therefore be specified both by a Definition of Done and by acceptance criteria.
Acceptance criteria in a nutshell:
– Always refer to a specific requirement
– A checklist of criteria for ensuring quality
– Tell us whether a supposedly finished requirement meets the original expectations of the stakeholders and can be set to "Done"
← back to list