Under what circumstances should acceptance criteria be allowed to change?
Changes are happening on our project and we have to respond appropriately. But under what circumstances should our acceptance criteria be allowed to change?
Acceptance (or completion) criteria are defined to make clear when a particular project deliverable, solution element can be considered complete and ready for the project's customers. They're essentially a quality control mechanism, established early in the project and used to judge progress and completion along the way.
After you've taken the time and trouble to define acceptance criteria expressing what this project needs to deliver, it seems reasonable that we wouldn't want these criteria to ever change. But that simply isn't realistic. Some acceptance criteria will evolve as more is known later in the project. And there are valid situations where the acceptance criteria must flex to accommodate changing needs or constraints on a project:
Acceptance criteria evolve as the project moves forward. You can expect that the project team will add detail to the acceptance criteria for different components as they learn more about the requirements and the solution. For example, the acceptance criteria defined for a solution at the start of a project will probably get updated before everyone reaches an agreement to deploy the solution. A core set of acceptance criteria focused on business value should form the foundation of your list. But as more is learned about the details of the solution, additional acceptance criteria should be added to the list.
Acceptance criteria may change when the requirements change. A project is like the ocean; the overall shape remains the same, but the individual waves rise and fall. Similarly, during a project, business needs can shift, priorities can change, and solution approaches need to be adjusted or changed. Naturally, the acceptance criteria will need to change with these shifting realities. When the requirements change, make it a standard step of your impact-analysis process to evaluate the change against the acceptance criteria. Look at what acceptance criteria this change would affect and ask yourself if this is a valid change in the customers' eyes. By allowing this requirements change, do you violate an acceptance criteria that is truly crucial to the project? This will help ensure that needed changes aren't rejected simply because they don't meet obsolete acceptance criteria and that the acceptance criteria stay in step with changing business needs, but also that such changes are made only after a full understanding of the impact.
Acceptance criteria may change when major tradeoffs are made. This is essentially a special case of the previous item—criteria changes driven by requirements changes. There are times when a project has to make major changes in scope, schedule, and/or budget, for example based on competing priorities among projects or sudden acceleration of an important customer's "need date." In this case, of course the project's completion criteria and major deliverables' acceptance criteria must stay in sync with the new definition of the project. Be sure to do methodical updates to the acceptance criteria as a key part of replanning elements of the project.
One warning: don't let the acceptance criteria change without careful consideration, especially in times of extreme urgency and emotion. Here's an example: The team has established, with cool, careful thought, that critical high-priority test cases must be passed and that every critical defect must be closed before the solution is ready to deploy. The worst possible time to allow changes to the acceptance criteria is at midnight of the last day of the testing window, when the team is feeling stressed and panicky over the looming deadline. Of course, the acceptance criteria may occasionally need to change at such a last-minute time; but on these rare occasions, try to eliminate fatigue and raw emotion as factors in your decision-making, evaluate the risks as objectively as possible, and make sure that critical project completion parameters are not being abandoned in the panic.