How to write a good user story — a practical approach
Writing a User Story that will satisfy all the stakeholders is a difficult task. Or is it?
A well-written User Story facilitates effective work for developers, testers, business analysts, product owners, and everyone interested in the project. But writing a User Story that will satisfy all the parties is a difficult task. Or is it?
What is a User Story?
There are a lot of good stories on Medium that talk about what a User Story is, and what it is not. I don’t think I need to reinvent the wheel, so let’s just see my favorite definition of User Story:
A user story helps agile software development teams capture simplified, high-level descriptions of a user’s requirements written from that end user’s perspective. A user story is not a contextless feature, written is “dev” speak. → story here
The key here it the user’s perspective. Remember — the User Story is not a piece of text for developers written in developers’ language. It should be understandable for all stakeholders, including the business side, that is not necessarily fluent in technology terms.
You should keep the User Story short, but detailed. Depending on the specific case, sometimes it is not easy to keep it that short but try to be precise and concise. The User Story should always concern one functionality only, and if it is too big, maybe it should become an Epic instead. Check this story to understand the difference between Epic and User Story.
What kind of information should a User Story have?
I have seen the whole range of information presented in User Stories. Depending on the project and workstyle of your team, you may prefer to use some of the sections, skip others or add something unusual for the particular User Story.
I am going to share with you the common template I use for writing User Stories during my everyday work.
1. User Story
As an Admin, I want to be able to assign tasks to Users so that I can delegate the work more efficiently.
I start with a traditional sentence a User Story usually starts with — As a <type of user>, I want <some goal> so that <some reason>. I try to be as precise as I can, but at the same time, keep the essence of the User Story in this one sentence and not overcomplicate it.
Think about this part in this way: By reading this sentence only, the person that is not involved in the project should understand the concept of the User Story well.
2. Background
The next part for me is usually the background of the story. I try to explain in a few sentences, why we even want this story to be developed, what it would change, and what the potential risks and benefits of the story are.
Currently, the manager needs to assign each task by e-mail or personally. This takes a lot of time and makes the manager work inefficient. We would like to implement functionality in our system, which will allow managers to automate their work. There is a risk, that not all the managers would know how to use this functionality, so the interface must be very intuitive.
This information should be enough for the developers to have an insight into the business decisions behind this User Story, and for the business side, it can be treated as a summary of the discussions about this User Story.
3. Mockup
If the User Story involves changing something in the UI, and it usually does, it is crucial to have some mockups done. Whether you are working with a UI/UX designer or not, these mockups can be more or less refined. It is essential to communicate clearly about what and how should change on the user interface level.
4. SBE (Specification by example)
I have seen this part named in many different ways. But the key is simple — what do I need to click to get the result that this User Story requires.
Log in as an Admin. Go to the “Tasks” page. Click on a task. You should see a field called “Assignee” where you can put the User’s name.
5. Acceptance Criteria
The Acceptance Criteria — the essence of the User Story. For me, this is the most important part, and usually the longest, that’s why I like to keep it as the last one. In this section, you should list all the detailed requirements to make this User Story come true. This is a guideline list for developers when developing, for testers when testing, and for Product Owner when accepting the User Story. You want to be as explicit here as you can, whilst keeping the criteria structured.
I like to have the criteria written in a form of a numbered list, adding indentations where I need to be more detailed. Remember to specify all the scenarios that are connected to the functionality. Should the field be mandatory or not? What happens if the user that was once assigned to the task deletes their account? Should the users see each other’s task? Or only their own? There are a lot of edge cases to every User Story, and specifying them in advance helps to improve the development process.
Do I need all of these sections?
Of course not! It always depends on the particular User Story you are working on. Sometimes it is enough to write the User Story and the Acceptance Criteria. Sometimes you need to add a custom section because of the specification of the User Story. Maybe you need to show what connections this User Story has with other User Stories? It is up to you.
Keep in mind, that in the end, the User Story has to fulfill its purpose — describe the functionality in a detailed, understandable way. There are many ways to achieve that, so why not experiment?
