the whole point of a user story is NOT to use a standard template as it is just a starting point for a conversation. Acceptance criteria are considered to be part of the Confirmation that the needs expressed in the Conversation were met.
For most folks, they'd use the agile work management tool (e.g. JIRA, Rally) to capture story information - the card, the conversation and the confirmation all together.
If you are referring to the card portion, the common approach of "As a user/persona, I want to perform some action/do something so that description of the real benefit of the story" but that is just one possible way of capturing the Who, the What and the Why...
Thanks Kiran. Probably from my question it was not clear but I was looking at help in terms of Technical User stories on lines of Gherking template.
I have altered my question now Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
My recommendation is taking a look to SAFe website and look inside for all related to Epics, Features, Stories. I am not a SAFe advocated (no matter I am certified) but I think you will find there good examples of Enablers stories which I closer to you are searching for. Saving Changes...
Beyond the usual "Given/When/Then" structure for scenario-based acceptance criteria, I'm not familiar with other formats which would be considered ad hoc standards.
Are you talking about user stories for non-functional requirements - security, performance, scalability, etc?
Rather than give a long answer from my personal experience that will probably be missing some context, I'm going to point you in a couple different directions and let you pick and choose the information you need.
When I googled "Technical User Story" the first result was an article from rgalen that does a decent job of addressing technical stories.
The next result, from Seilevel, addresses acceptance criteria and challenges associated with technial stories. It makes a good point, that technical stories often are not things that are easily demonstrated so they should be mapped to functional user stories.
There is a Technical User Story Writing forum on Scrum.org where someone who responds makes the recommendation that, for technical stories, you can make the system the user - it doesn't have to be a person. Alternatively, there is an article on the Exterme Uncertainty site that discusses "Why technical user stories are bad." Then, Agile Thought discusses 'The Five Hazards of Misusing "Technical Stories"' that is worth a read.
An article from Medium on "Writing Technical User Stories" gives the following example/template for technical acceptance criteria:
GIVEN: A {end user} is {doing the action} in the {app}
WHEN: The app hits the {endpoint route} endpoint with a valid request, containing {required request parameters}
THEN: The app should receive a status {code}
AND: In the response, the following information should be returned: {required response parameters}
Sample Request/Sample Response
There are varying thoughts on and approaches to technical stories; hopefully the above references provide you with some helpful information. Saving Changes...
Community Champion
