What are “real” user stories?
The essence of user stories as a foundation for agile development
This article is also available in German.
User stories are the essential foundation of agile workflow in our agency. They arise from the needs and expectations of end-users and thus, describe their intentions when using our software applications.
Our software applications are web products. Through the experience gained during the development of these applications, we realized how important it is to understand the essence of user stories and to be able to differentiate between “real” user stories and “pseudo” user stories.
User stories can be generated from a variety of different sources. The best source for user stories are end-users themselves as the less we need to speculate, the more likely we are to meet their actual needs. Therefore, we involve real users who represent our product’s target group within our development process. These end-users accompany us in the analysis and design phases through Design Thinking and provide critical feedback on our results after every development phase (i.e. product reviews after scrum sprints).
End-users often speak naturally in the form of user stories without ever having heard of the concept of user stories. They say things like:
“I would like to continue reading the article later when I’m on my way home without needing to find the exact spot where I left off.”
“I want to see the cheapest option first.”
“I would like to be able to log in using my Facebook, Twitter or Amazon account to avoid going through time-consuming registration processes.”
Since we know which end-users are formulating the story, we can replace the “I” in these real user stories with the user role. The first user story from above could then be:
“As a logged in user, I would like to continue reading the article later when I’m on my way home, without needing to find the exact spot where I left off.”
Since we are familiar with the application’s degree of development, we can rewrite some user stories to focus on the relevant aspects within the context of the use-case. The second quote from above would thus produce the following user story:
“In the search results, I would like to see the cheapest offer first so I don’t have to do any further research.”
For the same reason, a broad user story can be split into several smaller ones as it is important for the development team to limit the complexity of user stories. For example, this could lead to splitting the third user story into login types:
“As an unregistered user, I would like to be able to log in using my Facebook account to avoid going through time-consuming registration processes.”
“As an unregistered user, I would like to be able to log in using my Twitter account to avoid going through time-consuming registration processes.”
“As an unregistered user, I would like to be able to log in using my Amazon account to avoid going through time-consuming registration processes.”
By splitting the user story into three user stories, it is possible for the client to judge the business value of the various login types, since he is the expert for his user groups. If, for example, the software is a news website, the Amazon login user story could be given a lower priority. However, if the website is a news website for an Amazon merchant, the user story would be prioritized much higher.
Better than splitting the login user story into smaller ones, is identifying the user’s main needs and to leave the approach to the development team in finding a solution:
“As an unregistered user, I would like to avoid time-consuming registration processes to receive personalized news.”
This type of user story gives the development team the freedom to decide which solution can best satisfy the user’s needs. This way, the team may conclude that personalization through a cookie would work better than a login. The real user had different login methods in their mind when making the statement but did not necessarily know the best solution.
When discussing relevant business requirements with the client, it is not necessary to talk about concrete solutions as this is the development team’s task. The client only needs to know their end-users’ needs and wishes so that they can assess what added value is to be expected from satisfying these user needs.
Speaking from experience, it can even be counterproductive to talk about hypothetical solutions with the client. It is difficult and complex enough to agree with the client upon the relevance of user needs and its relation to the added value for them. If, during this discussion, we also talk about not fully thought out solutions, we run into the danger of losing focus of the actual goal.
The right setting to talk about solutions with the client would be during the assessment of the built implementation in the course of a product review.
If a user story is not in implementation, it is continuously improved upon, split, or joined with other stories, and is constantly assessed and prioritized based on user needs, business interests and feasibility.
The development team’s expertise is converting the user stories into a functional software solution. They may also adapt the user stories to work with them more efficiently.
Consequently, the perspective of the client is: “What business value does this user story have for my company?” while the perspective of the development team is: “How could the implementation of this user story look and how complex would it be to accomplish?”.
Herein lies the strength of requirements management through user stories: based on the same user stories, the expert knowledge of the client and the development team come together without losing focus on the end user.
User stories don’t contain specific detail requirements; instead they are the foundation for effective communication between all parties involved in the development process. Hence, they are formulated in short and easy to understand statements; it makes the user stories easy to skim through and allows everyone involved to use them quickly and expediently.
User stories that arise from real user needs have the following positive effects:
Support for Communication
- The whole development team focuses on the end user and never loses sight of his/her needs throughout the entire development process.
- End-users, clients, designers and developers understand the user stories and their meaning and can therefore, discuss them with ease.
- Everyone involved can comprehensibly test and assess the implemented user stories in a shared meeting.
Prioritization
- Clients can assess user stories according to their business value and discuss them internally with other departments.
- Less important requests are recognized early and implemented later (if ever).
- Implemented user stories offer a valuable use for the client (business value) and the end-user (user value).
Flexible improvements
- Since no set approach or solution is provided in fulfilling the user’s wishes, the implementation of the user story could potentially be worked out at any point in the software’s development process.
- As only important requests are implemented, designers and developers can focus on only the essential elements of the software and quickly achieve meaningful and successful results.
- By focusing on the important user stories, quality testing also has a clear foundation for test cases.
- User stories that have been implemented in a functioning software could potentially be immediately published.
What are pseudo-stories?
As time passed, our team’s approach to user stories also changed.
Ultimately, it became evident that it is a hindrance to include and work with so-called “pseudo-stories”. These were in fact, single tasks written in the form of a user story, which only related to technical preparation, the preparation of concepts and designs, and the pure implementation of code.
These “pseudo-stories” are not actually user stories but implementation tasks. Here, the principles of real user stories are turned on their head as the implementation of real user stories normally requires different tasks being assigned to it. In the “pseudo-stories” for UX, UI or web development, the tasks are disguised as user stories, resulting in the loss of their essence and benefits — even to the point of absurdity.
“As a developer, I want to define a scalable, relational database structure so that I can use it to implement any possible future use case.”
What business value does a great relational database have if the end user cannot use it? Only in a following sprint would the user be able to see and use an implemented user story that somehow uses the database structure in the background. However, what happens if the user story vastly overshoots the goal? It may contain data fields or whole data tables that, in practice, would never be required. Perhaps it turns out that the related user story becomes irrelevant in the following sprint as users can gather their data from another source. Additionally, a web service of a data provider could pop up in the meantime, which could be used instead.
Normally these kinds of “pseudo-stories” would be packed into a sprint that also contains additional stories that are related to it. The “real” user story can usually be found among these. However, with such an approach, a waterfall workflow is smuggled into the sprint, which ultimately waters down the focus on the end user and tends to result in unnecessary work and dependencies. These cost time and money without generating a concrete use for the client and the end user.
The aim of such an approach is usually to utilize the full capacity of all members involved in implementation, such as designers and developers, in a consistent and continuous way throughout a sprint. However, this kind of division suppresses the business value of the user stories and with it, an essential aspect of product planning from the client’s perspective.
How do we deal with a complex user story?
If we determine that a real user story is too complex for implementation within a sprint, then it needs to be downsized by the development team, either in the grooming phase (maintenance of the user stories) or, at the latest, in the planning phase of the implementation sprints.
Considering the database example (mentioned earlier), it may, for starters, be enough to set up a very simple database that meets all the requirements of a real user story. Perhaps all required data could be provided using a CSV file. If more user stories related to this solution were to come up in the following sprints, then this simple CSV solution could be completely replaced. This wouldn’t be so damaging as the implementation was simple and could be supplemented by other data sources and structures.
Since, according to the second agile principle, changing requirements that could provide a competitive advantage are always welcome, it is totally acceptable to completely discard solutions or modules and to replace them with more suitable ones in following sprints. What may seem like a waste will often present itself as a much more robust and neater solution as only the required complexity is implemented, resulting in better comprehensibility. In a follow-up sprint, refactoring can be taken into consideration during the complexity planning of a user story, which generally improves the readability and maintainability of code. However, such cases are rare according to our experiences.
The following video nicely depicts what a user story should look like and coincides with our experiences:
Summary
The point of view described in this article reflects the experience of a stable scrum team that has worked on multiple projects on a diverse range of web products.
In our experience as a team, user stories should arise from real user needs and serve as a communication basis between the client, developers, designers, quality testers and other involved parties. Implementation tasks are always subtasks of user stories, and not vice versa.
Finding solutions to user stories is the development team’s area of expertise and should be discussed with the client in product reviews after each sprint — not in advance. On the other hand, ideas and visions on a rough level can be discussed beforehand; most importantly the user needs should be determined and assessed.
Working software as the primary measure of success is an important agile principle, which leads to close collaboration between all disciplines without producing unnecessary documents and dependencies. This way, all energy is focused on fulfilling the user needs, which are formulated and prioritized in the user stories.
Topics for deepening
Further material
The Agile Manifesto
Values: Manifesto for Agile Software Development
Checklist: Principles behind the Agile Manifesto
Thanksgiving
Thanks a lot to Janko Hofmann, Dominique Duboc, Katrina Braun, Carlo Schulz and Jan-Sebastian Breitlauch for counter reading and the constructive feedback.
Special thanks to Chris Wan and Felix Weber for translating my article from German to English.
