S – Smart
M – Measureable
R – Relevant
T – Timed
Y – Why ?
The last one is interesting. I just found someone talking about it on the net. Its basically to help remember that a story should have a why ? Part.
AS someone I WOULD LIKE the system to do something for me SO THAT I can gain some benefit.
Acceptance criteria is the CONTRACT by which we agree with the client of the software we are writing what we will deliver.
Therefore it is the focal point of all parties involved. EVERYONE has an interest in what is contained therin:
THE CLIENT – This is how you make sure the team have understood what you want and how you MEASURE wether they have delivered it to you.
THE DEVELOPERS – this is how you make sure that you know the full extent of your work and thus how you know when you are finished with your job. Things outside the acceptance criteria which become apparent once you start a story must involve some kind of negotiation to append.
QAs – this is your lifeblood. It is impossible to determine if something is finished without knowing what its supposed to do. Acceptance criteria should be being consulted at every point in the develoment of a story. At the start, during and at the end. E.g. How many of the acceptance criteria have you met today ? This is what you will need to demo to the business.
BAs – you are the facilitator of the acceptance criteria. It is your job to negotiate between the ideals and desires of the client and the knowledge of the team of what is ACHEIVABLE within the given TIME PERIOD.
TEAM LEADs – these are what let’s you sleep at night. If there is well defined acceptance criteria the chances are that estimates will be more accurate and you will not have to explain why you have not delivered the functionality you guaranteed to the client.