User Stories are not User Requirements

21. May 2019

By Dr. Jörg Beringer, Senior Consultant Human-Centered Design, ProContext USA

As a trainer for Human-Centered Design (HCD) methods, I experience a lively discussion in almost every course 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 the rest of a Human-Centered Design process. And so my well-planned agenda always runs out of time on the first morning, because very basic questions arise and even after a long discussion not everything is necessarily clear.

Then I always wonder how it can be that such an well established concept like User Stories can still be so fuzzy and raises more questions than answers. That's why I decided to share here from the perspective of a Human-Centered Design expert how I see the actual role of user stories is and how they relate to the Human-Centered Design process.

User Stories live in the Solution Space

User Stories are an integral part of the agile development methodology to describe and prioritize the operating functions of an interactive system in form of a short narrative. Their granularity must be such that the described operating function can be implemented by the development team within a sprint (typically two weeks).

A user story is therefore a tactical tool for planning and controlling the implementation of a solution which is already defined - with or without previous requirement specification. When writing user stories, the focus is on the operative realization of the solution and not on describing unmet needs or problems statement suggesting the solution. This quickly makes it clear that a user story is merely the "human-centered description" of a (to be implemented) system feature, and not a (to be fulfilled) user requirement that is based on a user need.

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

A user story typically serves as a "Human-Centered Boundary Object" of a discussion between stakeholders, in which all participants can get an idea about the functionality of an interactive system from the user's point of view.

It is thus ultimately an informal form of specification in the solution space, which should help all stakeholders involved in the process not only to understand what is to be implemented, but also why and with what impact on the user experience. User Stories can therefore also be understood as a list of to be implemented operating functions of an envisioned solution, which enable a usage scenarios of targeted user groups.

Getting Informal Empathy Formally Under Control

Now let’s go back to where I started. We asked ourselves what a user story is and how a user story relates to a Human-centered Design process.

After we found out that a User Story is not a User Requirement, but an empathic description of an operating function to be built, many ambiguities are off the table, Everything would be fine if there weren't the user story templates which make a user story look like a user requirement:

  • As a [user], I can [capability], so that [goal].
  • As a [user] in [context], I [want] because [need].
  • As [persona], I can [what] so that [why].

This language sounds very user-centric, but often lacks any basis, because the actual user needs were not determined at all. In many cases a user story is based on the to-be-implemented feature itself in a self-referential way instead of referring to actual user goals or user requirements determined in the context of use.

The following examples are intended to illustrate some of the most common problems related to the use of empathetic language phrases:

As a user, I can enter my user credentials so that I can login.

Here simply the next step ("so that I can login") is presented as motivation of the first step ("enter my user credentials"). From a human-centered design perspective these steps correspond to sub tasks which are part of a higher level task. Only at the higher level, one could identify a user goal or need and describe it in form of an independent user requirements. From an implementation perspective, it makes sense to describe the chain of substeps so that the entire dialog flow is present to a developer.

As a user who sits in the car while driving, I want to set the temperature to 22 so that I feel comfortable.

This user story is already better because it describes the context of use and the operating function relatively neutrally. However, it is easy to confuse the described action with the goal itself. Setting the temperature to a certain degree is the method imposed by the solution, but not what the user wants to achieve (goal). The actual desired outcome from a users point of view is to have a comfortable temperature for a specific driving condition. This might be achievable in many (and better) ways than manually setting a target temperature.

This self-referential style of motivating an operating function recursively by the solution itself leads to an immunization trap where a potentially better solution is not identified because the current solution is implicitly taken for granted.

As a manager, I can print the meeting agenda, so that I know what’s coming up without using the device.

This user story is getting much closer to the concept of a valid user requirement, which defines what a user must be able to do with the interactive system in order to satisfy a need. However, the validity of this user story depends on whether there exist situations in which managers cannot use or do not want to use a mobile device. This requirement should have been derived from a context analysis before and codified as a user requirement independent of a user story.

From these examples, it becomes clear why the discussion about user stories regularly breaks the agenda of our training, because there is generally a certain concept uncertainty and the false expectation that a user story is a user requirement increases this concept uncertainty even further.

Even if user stories are supposed to be written from the point of view of a user, they should not be confused with real user requirements formally derived from user needs observed in the context of use. Iit is therefore important to understand that from the perspective of a Human-centered Design process, user stories do not replace an analysis of the context of use, but in the best case build on its results.

Structuring of user stories

Now that we've understood what user stories are and aren't, we can focus on the question of how to use them to scope of sprints and releases.

A single user story typically describes a partial functionality that is not independent of other user functions. Thus, user stories are not independent from each other, but describe an operating functionality to be implemented within a sprint that mostly serves a larger design objective.

There are various heuristics (rules of thumb), such as "User Story Mapping", which propagate the assignment of operating functions along tasks and subtasks so that the resulting solution completely covers a task flow of a user. This sounds logical, but in practice it is not as straightforward as it sounds.In a an MVP design (minimal viable product) only the happy path of a user task flow is implemented and many potential intermediate steps are intentionally omitted to reduce engineering effort. To ensure value to a user, it is important to understand the original goal of the core task and how the downstripping of functionality will affect task efficiency and effectiveness.

Overall, a task-oriented description does not always seem to be the panacea, because we are in the solution space, and the technical architecture of the solution under the hood now also plays a big role. Often, certain technical capabilities have to be built under the hood as a backend or web service in preparation for a desired user experience. Some sprints are simply dedicated to building such new "backend services", ideally derived from usage requirements in a human-centered design process.

For example, if a user shell be able to share a meeting agenda with all participants in order to inform them in advance, this means that under the hood collaboration services are required and must be technically enabled 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.

Basically, the topology (inner structure) of a usage scenario is different from that of a (technical) solution space. A human-centered quality objective such as "comfortable driving" can be reflected in various technical solutions and components of the technical solution space. For example, suspension properties, engine power, sound insulation of windows, upholstery of seats.

The structural incompatibility of the problem and solution space can be viewed as a "structural chasm" (gap), which endangers the continuity of a human-centered design process. It is therefore important to pay attention to the integration of these two phases. User stories carry part of the human-centered knowledge into the technical solution space, and help to understand the resulting solution from the user's point of view. But for scoping releases and prioritizing features, a solid understanding of the underlying user requirements is needed so that the resulting design is coherent and attractive from the user's point of view.

The difference between "Done" and "Fulfilled"

If user stories are only used for the purpose of project control in the sense of defining ToDos for scrum team, then a user story is considered 'Done' if the described operating function is technically complete and correct. The completion of a programming task (Definition of Done) is therefore measured by whether the functionality to be implemented is available and error-free. This definition of done is purely technical and focused on system quality under the hood and as such lacks human-centeredness.

Only if user stories are based on previously defined user requirements and user-related quality goals, then one can define acceptance criteria that measure whether a user story "fulfills" a specified condition or capability related to a user-centric design objective. This is also consistent with a general requirements engineering approach which tracks to what extent a solution fulfills requirements. Integrating user requirements into requirements engineering is particularly important in product areas that are subject to regulatory requirements, such as medical devices that can endanger patients' lives if used incorrectly.

At a glance

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

User Requirement User Story
Describes a requirement for the use of a functionality from the user's point of view Describes the functionality itself that must be implemented in a sprint
Is part of the definition of the interactive system at the beginning of the project Is part of the sprint planning during the realization of the interactive system
Must be fulfilled by the solution Must be done by the project team
Is justified by a user need in the context of use? Determined by the project team
Is the basis for the backlog Is taken from the backlog


Writing this blog now makes it increasingly clear to me why the discussion about user stories takes so much time. On the one hand there are many basic 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.

It is essential that Human-Centered Design (HCD) provides the basis for a valid agile implementation. While user stories live in the solution space and are subject to change with every redesign, the user requirements identified by a usage context analysis are rather long-lived and can be used across releases and projects.

We at ProContext therefore make it our goal to seed a better understanding of Human-Centered Design and establish concept clarity and a uniform terminology. In our advanced seminars, we create integration points with everyday topics such as the generation of a user-oriented backlog which is based on empirical data instead of assumptions of the project participants and which can be systematically re-prioritized and adapted in case of a redesign with maximum reuse of the underlying user requirements.