But all tests can be challenged. The challenge to this one is: implicit requirements.

Even if the “something-else that’s happening” does not “violate the acceptance criteria of any user story that the team has ever implemented and had accepted”, examples like the following are still defects in my book:

- Loss of data, with or without crash or stuck (I’m typing in my word processor and all that I’ve typed is not there)

- Intermittent extreme slowness

As a product owner, I might ask for another field to be added to a form, but I might not explicitly include acceptance criteria that says the field should align properly with other form elements and have the right amount of padding. If things are working right, the team will catch this and take care of it, either by making a good decision or asking for clarification.

The software development process is a cascade of successive elaboration. High-level features are broken down into stories, and detail is added. Stories are fleshed out with mockups and acceptance criteria. Acceptance tests are written which add more details about boundary conditions. Developers make additional micro-decisions as they do the implementation. We only really know the full definition of the story when it’s done at the end of the iteration; the goal with acceptance criteria is just to get enough clarity so that the team can plan their work accurately for the upcoming week or two.

My point, I suppose, is that acceptance criteria are often going to be too vague to use for this purpose, even in a team that functions well.

But i think the acceptance criteria of any user should have some blue print or evidance in the form of document/ requirement spec or discussed in CCC (Change Control Board)
What say.. :)

Really awesome article to distinguish between Defects & Enhancements as lot of experienced professionals fail to do so.