I would like to know if there is a go to way to best create user stories, keeping it consistent, and something easy for all of us to follow?
In the past we have used GIVEN, WHEN, THEN for acceptance criteria, but this format isnt a team favourite. It would be nice to know how or what way people create their user stories 
3 Likes
I see often managers starting to create work items(which they call stories) that only they understand. It can take months or years for people in the team to adapt to the style of the author.
Ask the team what could be changed.
Have backlog refinements and edit the story content to be understood by people.
Context matters, culture matters, language matters, background matters, business/product knowledge matters. So in each new context I would consider the working items are different. Although the user stories in the original sense(customer use cases) should stay similar and should depend on the customers and their relationship with the team.
Also, it’s important to keep in mind the difference between a working item and a user story. And then the different interpretations of a user story. Of course, in some contexts, these are used interchangeably.
In scrum for example there aren’t user stories in the backlog:
https://scrumguides.org/scrum-guide.html#artifacts-productbacklog:~:text=and%20their%20stakeholders.-,Product%20Backlog,-The%20Product%20Backlog
User Stories originate with Extreme Programming, their first written description in 1998 only claims that customers define project scope “with user stories, which are like use cases”. Rather than offered as a distinct practice, they are described as one of the “game pieces” used in the “planning game”.
What are User Stories? | Agile Alliance.
3 Likes
Sometimes I want to have (chunks of) good, old specifications back flavored with some explanations what problems the intended solution should solve.
I do not rely on a specific format for acceptance criteria.
More important for me is that:
- The authors feel good with them. That they represents what they want to tell.
- The team understands them.
- In one or the other way a team as influence on how ACs are written and by that they are authors too. Therefore this paragraph is just here to make clear that the (development) team is much relevant as the product owner.
1 Like
One approach that many teams find effective for creating user stories is “As a, I want, so that” format.
For instance-
“As a user, I want to be able to upload profile picture, so that I can personalize my account.”
This structure helps ensure that user stories are clear, concise and focused on delivering values to the user.
1 Like
1 - Explain someone’s pain
2 - Explain how we could tackle it
3 - Explain how the person will be affected by it
“as a user” is kind of a joke if one doesn’t represent that thought specifically from the user and it’s only someone’s demand. I had brave colleagues renaming that to: as a product owner, a slave, a team member, an agile resource or a developer.
The coincidence in the case above was that there was a heavy push on specific agile practices and processes onto the development team by people not in the development team. This made people very frustrated due to not having the right to choose what works in that context.
1 Like
Typically “User stories” have been created by product owners in my experience. Where development teams including QA have created “work items” based on those user stories. But I found I was creating user stories related to defects and qa activities. It sort of became the norm across many of the units of work. We used the “As a…” format and it worked for us.
-
Express the user statement (As a Developer/QA Engineer/User/Partner) describing the task or problem to be solved.
-
Give further context
-
Describe acceptance criteria
But it wasnt a hard rule. Sometimes you just wanted to describe a unit of work to be done. and that was fine too. But it did tend to cause more discussion and refinement if details were missing.