The four categories of an acceptance criteria

Being a person who has been part of some, or the other flavour of agile team for more than a decade. I was always wondering what is the best way to define and identify acceptance criteria for your story or epic or task or bug.

One of the best way to define and identify anything is to narrow it down on what needs to be identified what needs to be solved. So post narrowing it down you have to classify it to make it accurate and clear.

Now the next problem is how do I classify them. One of the easiest way to classify would be

  1. Musts: Requirements that must be met
  2. ought nots: Constraints defining what the system must not be or do
  3. Wants: Features that enhances the value of solution, value of solution but not mandatory
  4. Don’t wants: Behaviours of the system that reduces the value of the solution.

If we classify them like this, it will help us define better Acceptance criteria, and helps team to design required solution and enables teams to ensure a problem is well understood so that synthesis of possible design concepts can begin.

In the process of identifying constraints or potential barriers, teams can also reduce technical uncertainties.