Dynamic Acceptance Criteria?


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?



Comment List
  • I think it's important to attempt to come up with a reasonable set of well defined acceptance criteria upon initial creation of the story. This helps the team come to a consensus about what the story is really attempting to accomplish and often promotes thinking about the story at a deeper level. However, the reality is that things change over the course of sprint and stories have to reflect that. You may realize a design does not cover certain use cases, performance is not where it needs to be, or that requirements have changed. All of these (and more) can and often do lead to on-the-fly adjustments to stories and their accepting criteria. You also have to keep in mind that stories often don't exist in vacuums. Typically stories are related to other stories going on in the sprint and thus changes to one can ripple into others.

    So while it's probably good to give acceptance criteria some serious thought at the beginning of the sprint, there is a point of diminishing returns past which it's not useful to go. Where that point is depends on a lot of things like the size and complexity of story, where you are in the project, and how many people are doing tasks related to the story. It's a gut call to some degree that requires some experience and understanding of the system you're working on and the process you're working under.