How to write a good user story

If you're in software development these days you probably come across user stories at some point. In case you do, what makes a good one?

But first off, some background on what a user stories actually are and why people use them.

The Story Of User Stories

The story of user stories is basically a story about miscommunications on software requirements. When you're building a software system that fills the needs of others, you base requirements of that system on those needs. To do so you need information. If that information is encapsulated in tech speak requirements start to look like; "Just call endpoint X and parse to Y".

That's not what you want, if someone not understanding your tech speak is reading along. Going too far to the other direction is just as worse and causing developers to not understand what they are building.

So became the user story. Which describes the value of a functionality for the system from the perspective of someone who interacts with the system. This someone is typically categorized, like for example customer, gymnast and developer.

An example of a user story would be: as a customer I can pay with my credit card.

So what do you gain with this? Not much per se. There are alternatives available that are just as good. The value comes from a common structure. If done properly you can rely on the fact that each user story has a similar amount of information in a known format.

So what makes a good user story?

Now that we have a grasp of what a user story is. What makes a good one? So generally you want user stories to be:

Written from the perspective of one user.
Describing a function (not a solution).
Scoped to one function.
Describing a purpose of the function.
Not overlapping with other stories.
Contained, necessary information for developers and non-developers is present in the user story.

Learn more

If you can't get enough of user stories... there are some books I can recommend: