The Challenge of Writing User Stories
A user story is the smallest element of a product aimed at understanding the needs, motivations, and the users themselves. User stories are crucial for the development team and the product itself, as the team needs to understand who the user is, what they exactly want, and why they want it. However, most of the time, it is hard to build them.
Unveiling the Essence of User Stories
Every company, project, and even the team can have its own style of user stories, but like many other things, there are best practices in writing user stories too.
Using the format “As a user…, I want… so that…” is a very common way to create a user story. It has many advantages for both the development team and stakeholders.
“As a technical product manager, I want to write detailed and well-defined user stories so that we can build a magnificent product.”
When the development team first meets a user story with this format, they can easily understand the concept: Who will use this product, what they want to do or don’t want to do while using it, and what their purpose is?
On the other hand, when stakeholders read through a user story like this, they can identify missing parts, define other functionalities and purposes, and even identify other possible users easily. It means that we can have a better and common understanding among all the participants in the projects.
Navigating Non-User User Stories
But what if we have “spikes” for some technical dependencies or design-related investigation or a new API to produce data for another system? How can we write a user story for a non-technical requirement?
For the cases that we are talking about the investigation, it is still possible to use the “As a user…, I want… so that…” format since a developer or a team member will conduct the research. If the team is familiar with the concept and has a lot of good experience with it, we can assign the user as the developer or the team member. This may help them understand what is needed from them.
On the other hand, if there will be a new API or a new architecture, things can get more complicated. This time the value should be the focus of the user story, but it is still possible to use the same format with the “system” as the user. In the “I want” part, we can talk about what this new API will do while we are focusing on the value of this work for the other systems that will use it in the last part of the user story. With this, even the non-technical stakeholders can easily understand what the expected behavior from the system is for a specific operation.
Crafting User Stories for Efficiency
Like the format of the user stories, there are a few best practices to measure the quality of a user story.
INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) and SMART (Specific, Measurable, Achievable, Relevant, and Time-bound) are two very common ones. Even though they look like having different concepts, the main idea is the same for both of them. A good user story should be small enough to complete and create value in one iteration or sprint, significant, and clear enough to develop and test.
This leads us to another problem, which is how we will split the stories into small pieces. A common mistake that I believe most of the user story writers make while splitting the user stories into small pieces, like me, is dividing them into phases like “UI design”, “backend development”, “test”, etc. This creates dependent and non-testable or hard-to-test user stories, as well as not being valuable. However, we can find a better way to split.
If we have a workflow, instead of creating one story for each box in the flow (which is another common mistake), we should try to find out the most common cases for the entire flow and try to develop it first. With this approach, we will not only have a valuable and testable story but also have a chance to understand if there is any risk about the workflow.
If the process has steps in it, then we can create a separate user story for each step. This still has some dependency issues but we can have testable and small stories at least.
If we are building a product which has add, display, edit, and delete functionalities, we can create a different, small, and testable user story for each of them.
Conclusion
Good user stories are the key to creating a valuable product with efficient planning and engaged teams. Even though it is hard to write them, every team can find the best format for themselves throughout the product lifecycle.
