User Stories are not User Requirements

Introduction

As consultants and trainers for Human-Centered Design (HCD) methods, we experience in almost every workshop and course a lively discussion about what user stories are, where they come from, what they are for, whether they are the same as user requirements, and how they fit into a Human-Centered Design process. And so our well-planned workshops and seminars often run out of time on the first morning, because very fundamental questions arise around this topic, and even after a long discussion not everything is necessarily clear.

Then we always ask ourselves how it is possible that such an established form of description as user stories can be so vague at the same time and thus raise more questions than provide answers. That is why we have started to write this article from the perspective of a human-centered design expert to shed some light on what the actual purpose of user stories is and how they should be methodically classified in relation to the human-centered design process.

User stories live in the solution space

User stories are an integral part of the agile development methodology for describing and prioritizing the functionality of an interactive system to be implemented in natural language. Their granularity must be such that the described functionality can be implemented by the development team within a sprint (typically two weeks).

The user story is therefore a tactical tool for planning and controlling the implementation of a solution. In other words, the solution as such is already defined – with or without a previous requirements specification. It is only about the operational realization of the solution and not about the rationale of the solution design. This quickly makes it clear that a user story is merely a "human-centered" description of a system feature (to be implemented) and not a user requirement (to be fulfilled) justified by a user need.

Wikipedia sums it up nicely on the "User Stories" page: "A requirement is a formal description of a need, a user story is an informal description of a feature.”

The main purpose of a user story is to serve as a "human-centered boundary object" to facilitate communication between stakeholders about the functionality of an interactive system from the user's perspective.

As such, a user story is ultimately an informal means of specification in the solution space, designed to help everyone involved in the process understand not only what is being implemented, but also why and with what impact on the user. User stories can also be thought of as a list of system features to be implemented, which should serve to implement certain use scenarios for certain user groups.

Informally described empathy versus formal clarity

Back to the starting point. We asked ourselves what a user story is and how a user story relates to user requirements.

Once we realized that a user story is not a user requirement at all, but rather an empathetic description of functionality to be implemented, a lot of ambiguity went out the window. If there were no best practice templates encouraging product owners to always write a user story to sound like a user need or a user goal:

• As a [user], I can use [feature] to achieve [goal].
• As a [user] in [context], I [want] because [need].
• As a [persona], I can do [what] so that [why].

This language sounds very empathetic and like a user requirement, but often lacks any basis because the actual user needs have not been determined at all. Instead, they are spontaneously generated descriptions of an operating function of a proposed solution, which are recursively justified in the solution space (self-referential) and often do not even refer to user goals or user requirements derived from a context of use analysis.

User stories are usually written at a late stage, when the realization of a solution is planned. As a result, there is a tendency to simply enrich a to-be-implemented functionality with a persona and an empathic motivation or goal, without tracing it back to a solution-neutral user requirement documented by previous context of use analyses and subsequent requirements identification.

The following examples illustrate this:

“As a user, I can enter my user credentials to log in.”
Here, the next step ("so that I can log in") is simply presented as the motivation for the first step ("enter my user credentials"), which corresponds to a subtask in the sense of a human-centered design process. They have no value for the user and do not represent a solution-independent requirement. However, as a description of the operating functions to be implemented, it makes sense to describe the chain of subtasks so that a developer is aware of the entire interaction sequence.

Introduction

As consultants and trainers for Human-Centered Design (HCD) methods, we experience in almost every workshop and course a lively discussion about what user stories are, where they come from, what they are for, whether they are the same as user requirements, and how they fit into a Human-Centered Design process. And so our well-planned workshops and seminars often run out of time on the first morning, because very fundamental questions arise around this topic, and even after a long discussion not everything is necessarily clear.

Then we always ask ourselves how it is possible that such an established form of description as user stories can be so vague at the same time and thus raise more questions than provide answers. That is why we have started to write this article from the perspective of a human-centered design expert to shed some light on what the actual purpose of user stories is and how they should be methodically classified in relation to the human-centered design process.

User stories live in the solution space

User stories are an integral part of the agile development methodology for describing and prioritizing the functionality of an interactive system to be implemented in natural language. Their granularity must be such that the described functionality can be implemented by the development team within a sprint (typically two weeks).

The user story is therefore a tactical tool for planning and controlling the implementation of a solution. In other words, the solution as such is already defined – with or without a previous requirements specification. It is only about the operational realization of the solution and not about the rationale of the solution design. This quickly makes it clear that a user story is merely a "human-centered" description of a system feature (to be implemented) and not a user requirement (to be fulfilled) justified by a user need.

Wikipedia sums it up nicely on the "User Stories" page: "A requirement is a formal description of a need, a user story is an informal description of a feature.”

The main purpose of a user story is to serve as a "human-centered boundary object" to facilitate communication between stakeholders about the functionality of an interactive system from the user's perspective.

As such, a user story is ultimately an informal means of specification in the solution space, designed to help everyone involved in the process understand not only what is being implemented, but also why and with what impact on the user. User stories can also be thought of as a list of system features to be implemented, which should serve to implement certain use scenarios for certain user groups.

Informally described empathy versus formal clarity

Back to the starting point. We asked ourselves what a user story is and how a user story relates to user requirements.

Once we realized that a user story is not a user requirement at all, but rather an empathetic description of functionality to be implemented, a lot of ambiguity went out the window. If there were no best practice templates encouraging product owners to always write a user story to sound like a user need or a user goal:

• As a [user], I can use [feature] to achieve [goal].
• As a [user] in [context], I [want] because [need].
• As a [persona], I can do [what] so that [why].

This language sounds very empathetic and like a user requirement, but often lacks any basis because the actual user needs have not been determined at all. Instead, they are spontaneously generated descriptions of an operating function of a proposed solution, which are recursively justified in the solution space (self-referential) and often do not even refer to user goals or user requirements derived from a context of use analysis.

User stories are usually written at a late stage, when the realization of a solution is planned. As a result, there is a tendency to simply enrich a to-be-implemented functionality with a persona and an empathic motivation or goal, without tracing it back to a solution-neutral user requirement documented by previous context of use analyses and subsequent requirements identification.

The following examples illustrate this:

“As a user, I can enter my user credentials to log in.”
Here, the next step ("so that I can log in") is simply presented as the motivation for the first step ("enter my user credentials"), which corresponds to a subtask in the sense of a human-centered design process. They have no value for the user and do not represent a solution-independent requirement. However, as a description of the operating functions to be implemented, it makes sense to describe the chain of subtasks so that a developer is aware of the entire interaction sequence.

“As a user sitting in the car while driving, I want to set the temperature to 22 degrees so that I feel comfortable.”
This user story is better because it describes the context of use and the control function in a relatively solution-independent way. However, it is easy to confuse the described action with the goal itself. The desired state of having a comfortable temperature is the outcome (goal) that the user is actually aiming for. Setting the temperature to a certain number of degrees is the method imposed by the solution design but does not reflect what the user wants to achieve (goal). The danger here is that a solution is recursively motivated by the solution itself (immunization trap) and not the optimal solution is built (e.g., automatic air conditioning).

“As a manager, I can print out the meeting agenda so that I know what's coming up without having to use the device.”
This user story is more like a user requirement, defining what a user must be able to do with the interactive system to satisfy a need. However, this assumes that the need to sit in a meeting offline without the system has been identified in the context of use.

So, if we understand that a user story is an informal, emphatic description of an operational function to be implemented, and NOT an alternative phrase to formulate user requirements, then it becomes clear that user stories do not replace user requirements, which are based on a context of use analysis and inform a human-centered design process.

If we agree that user stories, as they are written in projects, describe functionality for the user to be developed within a sprint, it might be much more powerful to describe "user stories" in terms of the task objects and required operations to be delivered to the user during a sprint. In fact, we have clients who do exactly this to streamline the entire specification process and increase clarity for their product teams.

Structuring User Stories

Now that we understand what user stories are and what they are not, we can turn our attention to how to use them to prioritize user features and define the scope of sprints.

A single user story typically describes a sub-functionality that is not independent of other operational functions. Thus, user stories are not independent of each other, but describe an operational functionality to be implemented within a sprint, which usually serves a larger design goal.

There are various heuristics (rules of thumb) for this, such as "user story mapping", which propagates the assignment of operating functions along tasks and subtasks, so that the resulting solution covers a task completely. This sounds logical, but in practice it is not as easy as it sounds.

For example, when building a minimum viable product (MVP), many subtasks may be omitted from the solution description for efficiency, and only the ideal path from the user's point of view is implemented. In this case, at least the first and last steps must be supported for the supported task to appear in an MVP release and be evaluated by users.

Overall, a task-centric description of the system features to be implemented does not always seem to be a panacea, because we are now in the solution space, and enabling the technical backend of a solution is part of the job. Many sprints will be dedicated to functions that are under the hood and only indirectly enable experiences.

For example, if a user needs to be able to share a meeting agenda with all participants in order to inform them in advance, this means that (technical) collaboration services must be integrated under the hood before the interactive system can be built above the hood. It is therefore perfectly permissible to organize sprints not only on the basis of "human-centered user stories", but also on the basis of "system stories", which can be of a technical nature. While "under the hood" system stories should be organized by capability or technical data model, "above the hood" user stories should be aligned with task-centric user requirements. System stories should still be linked to an "above the hood" user story. For example, "driving a car comfortably" may be reflected in different technical solutions and components of the technical solution space. For example, suspension characteristics, engine performance, sound insulation of windows, upholstery of seats. But each of these technical components contributes to the human-centered quality goal of "driving a comfortable car".

This structural incompatibility between the problem space and the solution space tends to create a "structural gap" that diminishes the human-centered design process and shifts the focus to technology. It is therefore important to pay attention to the integration of these two phases. For above-the-hood system functionality that enables user interaction, human-centered user stories written to align with end-to-end task flows help to keep the focus on the user experience. For under the hood functionality, system stories are naturally organized by the technical topology of the system, but should be prioritized by human-centered design objectives to stay focused on human-centered quality and system purpose.

The Difference Between "Done" and "Fulfilled”

If user stories are only used for project management in the sense of ToDos for the developers working in the Scrum team, then a user story is considered "done" when the described operating function is technically complete and correct. The completion of a programming task (definition of done) is therefore measured by whether the new functionality is available and error-free. This use of user stories spins in circles within the solution space, as a feature to be implemented is described and the completion of the task is measured by whether the feature is present or not.

If, on the other hand, user stories are derived from previously derived user requirements and use-related quality goals, then it is possible to measure whether an implementation of a user story "satisfies" these previously defined user requirements. Only when used in this way is the use of user stories also a quality-enhancing method, because from a quality perspective the user story satisfies the requirements. Therefore, it is important to manage the solution-independent user requirements separately, and ideally to obtain the user requirements from the context of the use analysis in advance. This separation makes it possible to verify the extent to which the solution meets these user requirements. This is particularly important in product areas that are subject to regulatory requirements, such as medical devices, which can endanger patients' lives if used incorrectly.

At a Glance

The following table summarizes the differences between user requirements and user stories:

Conclusion

Writing this article helped us to better understand why the discussion about user stories takes so much time. On the one hand, there are many fundamental misunderstandings and false expectations about what a user story is. On the other hand, you need a solid understanding of the human-centered design process to understand how agile development methods and the human-centered design process fit together and complement each other.

In a human-centered design process, user stories are less solution-centric and more focused on use scenarios and task flows. They represent a pool of to-be-implemented user requirements and can be prioritized and selected to become the scope of a next agile development sprint.

It is essential that solution-oriented user stories used in an agile implementation are based on user requirements derived from a human-centered design process. This not only ensures an end-to-end user focus, but also makes such user stories more reusable. While in Scrum, user stories live in the solution space and are therefore subject to change with each redesign, requirements identified through Context of Use analysis tend to be long-lived and can be used across releases and projects.

As demonstrated by our AI-powered Product Context Analyzer service, a user requirement can be automatically reformulated as a user story to create solution-independent user story statements. This pool of rewritten user stories is the ideal foundation for user story mapping exercises, where the product owner selects a subset of user stories to define the scope of an epic or upcoming sprint. This practice ensures that user stories are written consistently and correspond to valid user requirements generated by the HCD process. By formulating requirements in user story syntax, user stories can be turned into a Trojan horse that injects requirements into Agile unnoticed.

About the Authors

Joerg Beringer and Thomas Geis have been working in user research, user requirements engineering, and conceptual design for the past 30 years. In 2024, Joerg and Thomas founded ProContext Inc., a Silicon Valley startup committed to delivering AI-first tools that help product teams gain a solid understanding of user requirements that serve as a comprehensive basis for informed design decisions.

“As a user sitting in the car while driving, I want to set the temperature to 22 degrees so that I feel comfortable.”
This user story is better because it describes the context of use and the control function in a relatively solution-independent way. However, it is easy to confuse the described action with the goal itself. The desired state of having a comfortable temperature is the outcome (goal) that the user is actually aiming for. Setting the temperature to a certain number of degrees is the method imposed by the solution design but does not reflect what the user wants to achieve (goal). The danger here is that a solution is recursively motivated by the solution itself (immunization trap) and not the optimal solution is built (e.g., automatic air conditioning).

“As a manager, I can print out the meeting agenda so that I know what's coming up without having to use the device.”
This user story is more like a user requirement, defining what a user must be able to do with the interactive system to satisfy a need. However, this assumes that the need to sit in a meeting offline without the system has been identified in the context of use.

So, if we understand that a user story is an informal, emphatic description of an operational function to be implemented, and NOT an alternative phrase to formulate user requirements, then it becomes clear that user stories do not replace user requirements, which are based on a context of use analysis and inform a human-centered design process.

If we agree that user stories, as they are written in projects, describe functionality for the user to be developed within a sprint, it might be much more powerful to describe "user stories" in terms of the task objects and required operations to be delivered to the user during a sprint. In fact, we have clients who do exactly this to streamline the entire specification process and increase clarity for their product teams.

Structuring User Stories

Now that we understand what user stories are and what they are not, we can turn our attention to how to use them to prioritize user features and define the scope of sprints.

A single user story typically describes a sub-functionality that is not independent of other operational functions. Thus, user stories are not independent of each other, but describe an operational functionality to be implemented within a sprint, which usually serves a larger design goal.

There are various heuristics (rules of thumb) for this, such as "user story mapping", which propagates the assignment of operating functions along tasks and subtasks, so that the resulting solution covers a task completely. This sounds logical, but in practice it is not as easy as it sounds.

For example, when building a minimum viable product (MVP), many subtasks may be omitted from the solution description for efficiency, and only the ideal path from the user's point of view is implemented. In this case, at least the first and last steps must be supported for the supported task to appear in an MVP release and be evaluated by users.

Overall, a task-centric description of the system features to be implemented does not always seem to be a panacea, because we are now in the solution space, and enabling the technical backend of a solution is part of the job. Many sprints will be dedicated to functions that are under the hood and only indirectly enable experiences.

For example, if a user needs to be able to share a meeting agenda with all participants in order to inform them in advance, this means that (technical) collaboration services must be integrated under the hood before the interactive system can be built above the hood. It is therefore perfectly permissible to organize sprints not only on the basis of "human-centered user stories", but also on the basis of "system stories", which can be of a technical nature. While "under the hood" system stories should be organized by capability or technical data model, "above the hood" user stories should be aligned with task-centric user requirements. System stories should still be linked to an "above the hood" user story. For example, "driving a car comfortably" may be reflected in different technical solutions and components of the technical solution space. For example, suspension characteristics, engine performance, sound insulation of windows, upholstery of seats. But each of these technical components contributes to the human-centered quality goal of "driving a comfortable car".

This structural incompatibility between the problem space and the solution space tends to create a "structural gap" that diminishes the human-centered design process and shifts the focus to technology. It is therefore important to pay attention to the integration of these two phases. For above-the-hood system functionality that enables user interaction, human-centered user stories written to align with end-to-end task flows help to keep the focus on the user experience. For under the hood functionality, system stories are naturally organized by the technical topology of the system, but should be prioritized by human-centered design objectives to stay focused on human-centered quality and system purpose.

The Difference Between "Done" and "Fulfilled”

If user stories are only used for project management in the sense of ToDos for the developers working in the Scrum team, then a user story is considered "done" when the described operating function is technically complete and correct. The completion of a programming task (definition of done) is therefore measured by whether the new functionality is available and error-free. This use of user stories spins in circles within the solution space, as a feature to be implemented is described and the completion of the task is measured by whether the feature is present or not.

If, on the other hand, user stories are derived from previously derived user requirements and use-related quality goals, then it is possible to measure whether an implementation of a user story "satisfies" these previously defined user requirements. Only when used in this way is the use of user stories also a quality-enhancing method, because from a quality perspective the user story satisfies the requirements. Therefore, it is important to manage the solution-independent user requirements separately, and ideally to obtain the user requirements from the context of the use analysis in advance. This separation makes it possible to verify the extent to which the solution meets these user requirements. This is particularly important in product areas that are subject to regulatory requirements, such as medical devices, which can endanger patients' lives if used incorrectly.

At a Glance

The following table summarizes the differences between user requirements and user stories:

Conclusion

Writing this article helped us to better understand why the discussion about user stories takes so much time. On the one hand, there are many fundamental misunderstandings and false expectations about what a user story is. On the other hand, you need a solid understanding of the human-centered design process to understand how agile development methods and the human-centered design process fit together and complement each other.

In a human-centered design process, user stories are less solution-centric and more focused on use scenarios and task flows. They represent a pool of to-be-implemented user requirements and can be prioritized and selected to become the scope of a next agile development sprint.

It is essential that solution-oriented user stories used in an agile implementation are based on user requirements derived from a human-centered design process. This not only ensures an end-to-end user focus, but also makes such user stories more reusable. While in Scrum, user stories live in the solution space and are therefore subject to change with each redesign, requirements identified through Context of Use analysis tend to be long-lived and can be used across releases and projects.

As demonstrated by our AI-powered Product Context Analyzer service, a user requirement can be automatically reformulated as a user story to create solution-independent user story statements. This pool of rewritten user stories is the ideal foundation for user story mapping exercises, where the product owner selects a subset of user stories to define the scope of an epic or upcoming sprint. This practice ensures that user stories are written consistently and correspond to valid user requirements generated by the HCD process. By formulating requirements in user story syntax, user stories can be turned into a Trojan horse that injects requirements into Agile unnoticed.

About the Authors

Joerg Beringer and Thomas Geis have been working in user research, user requirements engineering, and conceptual design for the past 30 years. In 2024, Joerg and Thomas founded ProContext Inc., a Silicon Valley startup committed to delivering AI-first tools that help product teams gain a solid understanding of user requirements that serve as a comprehensive basis for informed design decisions.