The team needs to work together as opposed to having a "Not my job, not my responsibility" type of attitude/mantra.
Acceptance criteria comes in the form of:
- Business Acceptance
- Quality Assurance Acceptance
Typically the business acceptance is usually answering the question:
- Does the feature that has been implemented do what I want it to do?
The feature will have a number of requirements that are business oriented, like if I press this button I expect this action to occur. It will list out the expected business scenario(s) and expected behavior but it will not cover all possible cases.
It is expected that business requirement should be defined prior to an iteration so that quality assurance can develop any technical on non-business requirements. Quality assurance should develop destructive cases as well as edge cases as needed.
Both sets of requirements should be reviewed prior to starting any story work so that a formal estimation and commitment can occur for the unit of work. Once this is done, the feature/stories can be worked on. At this point everyone is clear on what is to be delivered both from a business and technical standpoint.
The story reaches final acceptance once the business and quality assurance team members sign off on the story. This should happen during the iteration for both business acceptance and quality assurance acceptance. This is the definition of done (DoD) which signals additional story work can be started.
Any new findings may be logged as defects or additional story spikes. In a perfect world this would never happen, but in reality there is usually some amount of "discovery" that occurs when working on a feature/story. This is natural.
The team should work together (business, QA, developer) to hash out any nebulous discovery type of requirements. If this is agile, they all should be sitting at the same table to foster communication and quick resolution to any questions that may arise. It should go something like this:
"Hey, Developer we should handle this particular scenario. I've
discovered that if I input this data I get an error."
"That wasn't covered in any requirement, but we can add some
additional functionality to cover this. OK, Hey Business Person, how would > you like the application to behave for this case?"
"Let's show our standard error message and let the user try again for
this scenario. How much additional effort will then be?"
"It will be easy, only an extra hour or two. I can commit to for this iteration. QA please update your
acceptance criteria for this scenario, we don't need an additional story for this. Thanks!"
Or if it's a lot a work, a new story is added to the backlog. The team can still accept the original story as it is meeting all the original requirements, and then pick up the spike story in the next iteration.