A while back we discussed user stories, an important part of that is the acceptance criteria.
Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.
When we add in the acceptance criteria we spell out specifics that fill out our requirements. This can remove any ambiguity in the story that the developer may see. The criteria come from asking the Product Owner a few questions. We all make assumptions and that can get tricky as everyone has a different frame of reference.
A user story example:
As a job seeker I want to login so I can post my resume.
The user story gives us some information but it seems there might be some additional details we want to address before we start coding. When we say post a resume, what do we mean? Just upload the file? Or do we mean manually enter previous job experience?
Acceptance criteria can be gained by having a conversation with the product owner, the developer, and the quality assurance team member. Sometimes these questions will come up in an estimation meeting, this will help everyone agree on what is to be done.
The acceptance criteria should be spelled out in simple language and avoid the use of excessive business jargon. The acceptance criteria will serve as the minimum product requirements. When need to add any details at this point to guide the developer.
Example Acceptance Criteria:
- The login button needs to be blue and say “Login”.
- The password field needs to allow up to twelve characters.
- The password must contain one number, one letter and one special character.
Once the developer has completed their work, they can hand it over to Quality Assurance. Then the Quality Assurance can test the new feature thoroughly with the criteria in mind.