Usually during the early stages of a project projectmembers put a lot of effort in identifying stakeholders and their goals, examining documentation, identifying business processes and elemtary business process, estimation on complexity. Later on this is all sowed together in a project proposal. So everyone is informed about all the things mentioned before and the go's have been given. One very important step has not been taken. How and when will the customer accept the project deliverables. When are you finished with your projects. When all the deliverables are delivered? Or perhaps when everything is done.
But along the line when you start executing iteration after iteration your customer lags accepting the things you deliver each iteration. Because the customers customer is enjoying his or her holidays and is off for 4 weeks, or the color of the buttons is red instead of blue or the end user group is so big that nobody has the guts to accept.
So what do you need to do?
- Make acceptance criteria explicit as early as possible. When you first ask the customer for acceptance criteria he or she will say when all the work is done. When that is the case you have to come up with more explicit questions about functionality asked and how that little piece of functionality will be accepted. This opens the door to more concrete acceptance criteria.
- Find out who is authorized to accept. What will happen when the one authorized is not in for a while, e.g. for the time of two iterations. Hey these things happen! Just do not take criteria for granted because it will ruin the velocity of your project in many ways. Stockpiling your use cases in Test phase. Which easily could lead to a lot of rework once the acceptance process is executing. Which leads to extra pressure on finishing the project. Besides all, the project is never going to end!
Enough reasons to make acceptance criteria explicit I'd say.