How to Write Great User Stories

“User story is an informal, natural language description of one or more features of a software system.”
In modern software development, user stories are one of many steps to a successful implementation of the Agile approach. If you aren’t yet familiar with Agile, read this article beforehand.
In Agile, there are many different terms and principles that need clarification – so today we want to share some insights about what user stories are and how to successfully write them.
Now let’s dive into details.
As a "Who", I want "What" so that "Why".
"Who" here means a person interacting with the product, "what" means an action or a process of interaction and "why" means the end goal of that interaction (why it should happen in the first place).
"As a Sports Fan, I want to view the score of the latest match so that I knew if my team won".
That's it! Although user stories may look primitive, especially to a seasoned business analyst who’s used to describing everything in detail, their simple structure is the reason they’re so popular and widely-used in Agile software development.
NB: User stories are usually written by product owners. This is one of the roles in this particular software development approach as described here. The Product Owner can be from the developer’s side or the client’s side, or can be a third-party.
They have a vision of the project, collect all the ideas into a wish-list (backlog) and translate it to the developer’s team. One of the ways of effectively explaining the necessities of the future product is to describe it in the format of User Stories.
The idea is that you as a product owner will be able to look at a user story, quickly recall a feature and be able to explain it to developers or stakeholders.
So how do I write a genuinely useful user story for task-setting during development? Though dozens of books have been written about applying user stories, it's not that difficult to start creating the stories for your project just by following the guideline below.
A distinctive principle of user stories is "people go first".
A simple structure saves you time on going into unnecessary details.
Dismiss from the feature any actions which add no value.
The "What" is a way to briefly explain how the functionality you're building will actually work.
For example, "catalogue". Everyone imagines more or less the same thing when they hear "catalogue": a list of items with images/names/sometimes descriptions.
User stories are not a stand-alone tool. They are meant to help trigger a conversation with everybody, describing what you mean in detail.
Your stories aren’t going to participate in a “Best User Story” competition. Just make sure you’ve explained your idea loud and clear and that the developers get it.
The third step is where you finally capture the purpose of building the feature you're working on.
To compare with the "Football Fan" example above, here's an example with the same User but a different "Why":
As a Football Fan, I want to blow a Vuvuzela so I can support my team.
This one also has a "Why", but... Can you see the difference?
Does a Vuvuzela meet the need to support my favourite football team? Perhaps. Maybe there are other ways to support them, like cheering or buying merch?
That's everything you need to write productive user stories. Also remember, no matter how professional you as a product owner are, always show your stories to your team and discuss them together. Improve and rewrite them with the help of your colleagues to ensure the highest possible quality. You won’t be able to achieve it alone.
Acceptance criteria are a vital component for the assessment of user stories’ potential for successful realisation after the coding is done.
Coming back to the Football Fan example, these would look something like this.
"As a Sports Fan, I want to view the score of the latest match so that I know if my team won"
In case you prefer a more detailed explanation of user stories, watch this video.
A good user story is a well-balanced description, neither too detailed nor unclear. You should say just enough to fully encompass the value that the given feature needs to deliver. It should be clear, concise and objective.
However, if the case is too complicated, there are two ways to handle it:
For example, if you want to enable the user to share content on social networks, do not write “As a user, I want to share content on social networks”. It’s too vague. Write: “As a user, I want to share content on Facebook…”, “As a user, I want to share content on WhatsApp…” and so on.
For example, our user story “As a user, I want to share content on social networks” stays the same, but the acceptance criteria are sharing on Facebook and WhatsApp.
How do you choose between the two approaches? If the feature is too big to be realised within one iteration, subdivide it. If not, opt for the second option.
That was our guide on writing user stories for successful apps and software. If you’re willing to learn more about how we work with Agile, stay tuned for new posts.