A lot of user stories are not user stories

In addition to user stories, we use business stories and technical stories.

User Stories

If you’re working in digital product development, then you know about user stories. They are declarations of a feature for a specific user role to achieve a certain goal. And they are often written as:

As a <user role> I want to <activity or task> in order to achieve <user value>.

User stories center on actual user tasks and they are aimed at delivering user value. These user stories should be built and validated with actual users.

Business Stories 

“In the back office {company} only receives validated applications.” This real-life story (wrongly posited as a user story) is important to the business and not necessarily to the user. As long as his application is processed, the user probably doesn’t care how that is done.

Business stories are aimed at the business with the goal of delivering business value. Business stories should be written and validated with the relevant business stakeholders, who are knowledgeable about the subject of the story. That way, all the important details can be unearthed that are needed for the successful design and development of the product. 

As a <stakeholder> I want <requirement> in order to achieve <business value>.

Technical Stories

A back log consists of user stories. However, we often find items in there that developers need to do on their way to completing the user stories. And if they’re not on the back log, you can’t work on them. That leads to “user stories” like:

“As a resident I want to communicate with a consultant through the cloud, so that I know that my exchange is handled in a secure way”. Obviously, the wish to communicate with a consultant is valid. However, this story includes the means (the cloud), which most users don’t care or don’t think about. And, arguably, the same is true for security of an exchange. 

Should we delete that part of the story? Of course not. If the designated solution is to work with a cloud, then that should be part of the back log. But be clear about it and don’t hide it in a user story.

In a lot of texts about the subject, this type of user story is often called a “technical user story”. If you think about it, that means the word “user” has lost its meaning in this construction. Bob Galen, who wrote books like “Agile Reflections” and “Scrum Product Ownership”, defines a technical (user) story as “…focused on non-functional support of a system”.

Bob prefers to write these stories down without trying to shoehorn it into a “user story” type sentence, but rather to “quantify the need (technically), in clear English with perhaps a couple of sentences, and then move on.”

Creating the right product

Masking business and technical stories as user stories leads to losing sight of the user. It ensures that all the business and technical requirements are met. Because every user need is placed in the context of this one product.

We often see that that process leads to a lot of assumptions about users as well, based on the knowledge that people have of their own product.

That’s not how users look at things, though. They live in a world where the product is just a part of their daily lives. They also use the product as part of a larger process and ecosystem and those lead to other requirements. Requirements that could be crucial to the right design of your product and that you could lose sight of when you don’t work with “pure” user stories.

In a nutshell

For business stories you talk to stakeholders. For technical stories you talk to architects and developers. For user stories you talk to users.

You might also like:

An introduction to value driven design

Clarifying producer values: the secret of valuable UX projects

Buyer values in the design process: when 'why' matters more than 'what'

Upgrading from feature driven to value driven development