A typical development and testing activity normally begins with taking a user story and digesting the information in it. From this shared understanding, we start to construct a set of use cases as a means of verifying the implementation and its completeness.
You could say that the story is complete once all the use cases have passed testing. The user story has now made it to the next stage and is being validated by the User Acceptance Testing team. The UAT team report a number of issues and the development team start to triage them.
While issues are being discussed and triaged, there could be this one particular “bug” (let’s call it bug x) but you may be thinking: “Is this really a bug or a feature request? Did the customer specifically ask for this scenario, or was it missed in the story refinement session prior to development? Also, is this the development team’s fault, who didn’t think about this scenario, or is it an entirely invalid use case?”
So, the development team become defensive and start to push back on the reported issue (bug x) arguing that this was never stated as an agreed acceptance criteria, while the UAT team are adamant it’s a bug.
Unfortunately, in some cases, there is no direct relation between a bug and acceptance criteria or a user story. If that was the case, the development team would know about it before UAT had their hands on the software.
If we can trace a bug directly to particular acceptance criteria on a user story then that is clearly a missed or an incorrect implementation.