Acceptance Criteria Question

The Scrum Guide says that during a Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

A User Story is a placeholder for a conversation about a possible requirement, and (as per the INVEST criteria) is negotiable.

What doubts were there, during your discussions, as to whether or not acceptance criteria might be adjusted in your situation? Might such adjustments cause quality goals to decrease, for example?

It's important to note that the Scrum Guide doesn't make any mention of acceptance criteria, so it is neither a requirement to use it, nor to keep it constant at any point.

The Development Team can inspect and adapt the Sprint Backlog in any way it sees fit, in order to help it meet the Sprint Goal. This could include removing items, adjusting the items that are there, or adding new ones.

The Product Owner is accountable for the Product Backlog.

Although software tools will often force the same item to belong to both backlogs, the Sprint Backlog and Product Backlog are separate artifacts, and are often adapted separately.

As long as the Development Team respect the Definition of "Done", and are accountable for the increment they produce, what harm could come from them adjusting the acceptance criteria?

If the Product Owner is ultimately not satisfied that a particular Product Backlog Item was completed in the increment, he or she might decide to keep it on the Product Backlog.

According to scrum guide "No changes are made that would endanger the Sprint Goal" + User story is a placeholder for discussion. Again scope can be clarified and renegotiated. Also often times, based on the new findings of the finished Sprint backlog items it could be a wise decision to UPDATE the acceptance criteria to be more meaningful and helpful for the development and testing of that PBI. As long as the update is only enhancing the quality and clarity of the Sprint goal you may as well update the Acceptance criteria.

Also note that there is no prerequisite for a Sprint planning meeting, which means the team may take in PBIs that are not READY (completely groomed yet) and this means some acceptance criteria are further defined in the refinement sessions during the Sprint (even though a matured Scrum team usually gets habituated to groom PBIs that are 1-2 Sprint down the road)

Thanks so much for everyone's feedback. By modifying our acceptance criteria the quality didn't decrease but I'm going to focus our attention on defining our Sprint goal.  

Our example was that there were more specific error messages that would give more information to the user about what caused the error, so we enhanced our acceptance criteria to include more detailed error messages, and our development team and product owner negotiated to update the story. 

Todd, I feel your last statement is spot on: 

"our development team and product owner negotiated to update the story"

Per the Scrum Guide (and previously cited by Ian:

"Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned"

In my opinion, what is most critical is that any potential change to a sprint item should be negotiated between the PO and the Dev Team (communication, collaboration), so that everyone is in agreement, the Sprint Goal is not impacted, and any changes to the Sprint Backlog to accommodate such changes (if any) are discussed.

Thanks so much for everyone's feedback, it's helping me immensely! :) I've been reading up on how to create effective Sprint Goals, if anyone has any links for suggested reading please attach to this thread.