I've been reading about Acceptance Criteria for User Stories and it seems that there are two distinct schools of thought. The first is that Acceptance Criteria is a wishlist of ideas proposed by the product manager that the developers will use as a guideline when they start working on the story. The other is that it is the minimum requirements necessary to consider a user story complete.
It seems to me that it can be both, depending on where in lifecycle of a user story you are. A user story is typically a a single sentence, sometimes two, that conveys an idea. How can a team pull that story and based on a single sentence determine what the parameters are for the story and whether or not they can accomplish it within a sprint? They have to have more guidance (like a wishlist?) from the product manager but not all of the items may be realistic.
Can Acceptance Criteria be dynamic? Can it start as a wish list, get defined during sprint planning and finalized during the sprint? Or is it something that has to be set in stone as benchmark at the beginning of the sprint?
During a recent sprint retro, one of the developers said he felt as if the sprint had truly been "agile" because they were able to progressively elaborate on the stories and the acceptance criteria as the sprint evolved and they learned more about the story. To me that is "Agile" but it seems to go against the acceptance criteria established at the beginning of the sprint as being definitive, which is what I read about in blogs and Agile documentation.
When I read about Agile, it says that all of the criteria must be met to consider a story "done" and that you can't give partial credit. Is it cheating to change the acceptance criteria on the fly or is it "progressive elaboration"? Where does your team draw the line?