As a user, I don’t want to
Task-oriented user stories lead to bad product decisions because they mix up value with cost. But they are easy to turn into inverted user stories — a tool for thinking bigger.
Since their invention in 1997, user stories have become ubiquitous. The simple format of “as X, I want Y so that I can Z” has helped countless software teams stay focused on the value they are providing for their customers.
In theory.
Scrum manuals and Agile coaches have drilled the format into product owners for decades, to the point that “user story” and “ticket” have become nearly synonymous. In an effort to fit their work into the Scrum process, teams have lost track of what the user story was meant to help them achieve. The user story went from
As [user] I want [to reach a goal] so that I can [obtain a benefit]
to
As [user] I want [to do a task] so that I can [use the tool]
I want to click the button so that I can see the page. I want to enter my email so that I can receive exclusive offers. I want to fill out form 1234-A so that I can fill in line 5 on form 5678-B. Sometimes, even the “so that” is missing entirely: As a user, I want to log in.
The truth is: I don’t want to use a product at all.
The ideal user experience is that I reach my goal without doing any work. The original user story format reminded us of this by staying focused purely on the goal. Task-oriented user stories replaced the goal with the work: all downside without any of the benefits.
Fortunately, it’s an easy fix. We just need to invert the stories.
What’s so bad about tasks?
The most important thing about the original user story format is that it outlined a benefit, for which users might be willing to pay. The product team would be free to figure out both how to provide the benefit and what its costs might be — including the cost of dealing with increased product complexity that users would have to face.
But tasks, tools, and features are not benefits. Doing a task or using a tool is one of the costs that the user has to pay to achieve their goal. Adding features to your product degrades the experience because it increases that cost.
Rather than helping the team make these trade-offs, task-oriented user stories make them harder by obfuscating the lack of value to the user. Asserting “as a user, I want to fill out the form” fools the team into thinking that the user will give the product something for nothing. The cost is hidden because the user is defined as someone who wants to fill out forms, even if no such person actually exists.
With a user story like that, every ticket becomes self-justifying. Features multiply, complexity rises. The value to the user plummets but teams cannot see it because they are constantly telling themselves that they are building what the user wants.
But the task-oriented user story is not entirely useless, as long as you know what to look for.
Invert the user story
A task-oriented user story contains two useful pieces of information, hidden behind inaccurate labels: what it calls the benefit is actually the cost, and what it calls the goal is a solution hypothesis. We can make use of this information to craft a new type of user story.
Take the task-oriented user story:
As a user, I want to customize my toolbar so that I can optimize my browsing experience.
Recognizing that we are looking at a cost, we can ask ourselves: is there a way for us to remove that cost?
As a user, I want to optimize my browsing experience without having to customize my toolbar.
Rather than taking for granted that the user should bear the burden of editing their own toolbar, the team can now think about what a better, less costly experience might look like. Instead of making it easier to customize the toolbar, we can skip directly to the real benefit.
This framing also highlights that the feature idea is, in reality, a hypothesis. Do users actually want to optimize their browsing experience? In what ways? A team that writes task-oriented user stories is stuck with their assumptions. A team prepared to invert their user stories is now equipped to actually find out.
Working Backwards
It’s easy to write task-oriented user stories, because they usually don’t describe innovative capabilities. Rather, they capture an existing pattern so well-known that it becomes obvious. Of course our users want to customize the toolbar! How else would they optimize their browsing experience?
If a user benefit brings an obvious feature to mind, chances are that it’s a feature that already exists somewhere else. But like all features, it represents a cost. And an existing cost is a great place to find pain points.
Rather than copying their competition, the team that inverts its user stories has identified an opportunity to get ahead of them. Amazon takes a similar approach to highlighting pain points in its press releases, with a slightly different phrasing: “today, customers have to…”.
“Today, customers have to customize the toolbar if they want to improve their browsing experience” sounds much more like a struggle than a feature you should build on purpose. Interrupting the rush to add a new ticket to the backlog has now turned into an opportunity to innovate and differentiate your product in the market.
