Here's the format that my team is currently using for User Stories and Acceptance Criteria. These formats are primarily learned from Scott Bellware's training that we have had recently, but is also influenced by the actual project that we are currently working.
As a [Role], I want to [Goal], so that [Motivation].
Role: Who is using the system
Goal: What you want to do with the system
Motivation: Why you want to use the system.
I typically see people asking questions about Motivation - why it's important, etc. It's important because it gives the implementer a frame of mind for the behaviour.
Example:
As a Nurse, I want to record patient pain levels, so that I can adjust their medication doses appropriately. vs.
As a Nurse, I want to record patient pain levels, so that I can adjust their medication doses appropriately.
vs.
As a Nurse, I want to record patient pain levels, so that I can show the pain trends with certain types of medication over a period of time.
When I read these two stories, as a developer, I begin to see drastic requirements differences and expect certain Acceptance Criteria based on the requirements differences that I expect to see. If I'm only adjusting their medication level, I probably only want to see what their current pain level is and whether or not I can adjust the level within dosage limitations. If I'm monitoring trends over a long period of time, I will want to record more - dose for period of time, when adjusted and why for the pain level, what other medications were involved in that patient in the same time periods, etc. The motivation can cause a huge difference in how the story is implemented.
I've noticed that there are two types of Acceptance Criteria: Behavioral (functional) and technical (non-functional). As such, there may be two different formats for a story.
When [verb], should [verb], should ...
When recording the patient pain level Should represent the level on a scale of 1 to 10 where 1 is no pain and 10 is extreme pain
Should [technical detail]
or
When [functional criteria], Should [technical detail]
The pain level recording screen must be usable via a touch screen tablet pc. or When recording patient levels on a tablet pc, the data should be cached locally and synchronized to the master database when the nurse docs the tablet pc.
The pain level recording screen must be usable via a touch screen tablet pc.
When recording patient levels on a tablet pc, the data should be cached locally and synchronized to the master database when the nurse docs the tablet pc.
I believe the functional acceptance criteria should be stated in technology and implementation agnostics terms - imagine for a moment that you are going to implement the requirements via building blocks, paper forms, or printed circuit logic. If you have to change the functional acceptance criteria based on the implementation technology, then the criteria is not formatted correctly in the first place.
Avoid joining functional and non-functional acceptance criteria into a single acceptance criteria. It is easy for a developer to lose sight of the behavioral goals when these are mixed, and may prevent a UI/UX specialist from creating the greatest workflow ever.
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.