Problem/roadblock: Users log in more if they can do it fast and easy
User story: I want to log in with my social media credentials to avoid having to remember mail and password.
User story: I want to be able to log in with email and password so I don't have to be logged in with a social media account on the computer where I want to log in.
In the best of situations, this is something that has been worked out with all involved in a project. The project owner, customer, developers, UX, designers, testers, management, sales. If they are all part of the process of creating user stories they will all understand the most important aspect of the project, why it is done at all. This will help all the way from the first test being written to the launch and beyond. When the customer checks in, and he should, and sees that the UI is very bare and there are just a few strange tests in place, it's not uncommon that he panics and feel like there's nothing done yet, why have you wasted so much time on a few tests when you could have made those features and a couple of more in that time? With agreed upon user stories in place, things look different. The barebones UI is in place only to facilitate the tests since it will most likely be changed later. The customer can see, or at least after a quick explanation, that each test is done to secure that a user story is met. The user stories in this example illustrate the problem in a less abstract way. Tests are connected to user stories rather than the problem since it reminds everyone why they are done. The same goes for decisions in UX, they are connected to user stories since it is less abstract than connecting them to the problems they are supposed to solve.
User stories are simply illustrations of solutions to a problem. When all user stories are met the problem is overcome. When all problems are overcome the business goal is met. When all business goals are met the product is ready.
Fred is a software jack of all trades, having worked over the last 24 years at every stage of the SDLC and has authored [two books](https://www.amazon.co.uk/Fred-Heath/e/B08F3Q1H1M).
User stories are simply illustrations of solutions to a problem.
The thing is, there are plenty of people who say otherwise. They think stories are requirements, functionality, goals and many more. Now, if you, your colleagues and all of your stakeholders agree on your definition and read/write stories with your definition in mind, then that's great. Otherwise, I wish you good luck.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is my personal take on user stories:
In the best of situations, this is something that has been worked out with all involved in a project. The project owner, customer, developers, UX, designers, testers, management, sales. If they are all part of the process of creating user stories they will all understand the most important aspect of the project, why it is done at all. This will help all the way from the first test being written to the launch and beyond. When the customer checks in, and he should, and sees that the UI is very bare and there are just a few strange tests in place, it's not uncommon that he panics and feel like there's nothing done yet, why have you wasted so much time on a few tests when you could have made those features and a couple of more in that time? With agreed upon user stories in place, things look different. The barebones UI is in place only to facilitate the tests since it will most likely be changed later. The customer can see, or at least after a quick explanation, that each test is done to secure that a user story is met. The user stories in this example illustrate the problem in a less abstract way. Tests are connected to user stories rather than the problem since it reminds everyone why they are done. The same goes for decisions in UX, they are connected to user stories since it is less abstract than connecting them to the problems they are supposed to solve.
User stories are simply illustrations of solutions to a problem. When all user stories are met the problem is overcome. When all problems are overcome the business goal is met. When all business goals are met the product is ready.
Hey Tomas,
The thing is, there are plenty of people who say otherwise. They think stories are requirements, functionality, goals and many more. Now, if you, your colleagues and all of your stakeholders agree on your definition and read/write stories with your definition in mind, then that's great. Otherwise, I wish you good luck.