The 3 traps to avoid when writing User Stories
Or "How to write better User Stories"
Writing a product requirements doc (PRD) is one of the most important tasks of a product manager. If done correctly, this effort sets up the team for success and for the business to drive results. If done poorly, the team will likely struggle to ship anything of real value. The most critical task of writing the PRD is that of crafting the user stories. These stories not only act as the guiding light for what the team should build, but also ensure you’ve addressed the user needs. And the most challenging part about writing a user story is making sure it succinctly illustrates the user problem.
The construct of a user story is simple - and most product managers are well versed in the nuts and bolts of what goes into it. But there is also nuance that must be evaluated. A user story should not be too prescriptive; it should give the team freedom to solve the need in new and unique ways. The basic construct of user stories that most people are taught is:
“As a [user], I [can/want/need] [something], so that I [can do something]”
Over the years I’ve learned that this structure does more harm that good - and I’d like to propose a simpler alternative:
“As a [user], I [can/want/need] [something]”
The reason for this simpler structure is that the original format has competing qualifiers that can lead to at least three traps:
Including clarifying factors
Including a solution
Including why the user wants to do the need
Over the past 12 years I’ve found that adding these qualifiers to the user story leads to poor results. Let me take you through some examples for each and the issues that can arise from these 3 traps.
Trap 1: including clarifying factors
One of the more challenging things about writing a user story is when the user need is contingent on other factors that can change. An example of this is something like “nighttime reading”. The same user might have different needs during the day vs at night. While this is true, constructing a user story where the clarifying factors are part of the needs statement can get messy. Take for example this user story:
“As a user, I need to be able to easily read the text even at nighttime”
This seems to follow the simple format I’ve suggested above but if you look closely the addition of “even at nighttime” has been bolted on. One takeaway from this example is that the solution has to work equally as well for daytime AND nighttime use cases. This forces the team to consider the best average solution. But what you really want is the team to think deeply about the two states of the user separately. And given that this clarifying factor is actually a user property, it’s better to move the clarification onto the user itself. This change might result with two user user stories such as:
“As a daytime user, I need to be able to easily read the text”
“As a nighttime user, I need to be able to easily read the text”
By moving the clarifying factors from the need statement onto the user property you can more succinctly and directly talk about potential solutions for the separate scenarios. This is a better approach than trying to cram everything into one watered-down solution.
Trap 2: including the solution in the user story
Sometimes you will be writing a PRD that has a somewhat pre-determined solution. This happens with technical solutions that the team might have landed on to generate the PRD. But it can also occur with solutions that you’ve come up with during user research. An example of this at Wonolo is from an initiative to overhaul how our customers can post jobs that recur on a set shift schedule. The team started referring to the solution as “recurring shifts” and quickly fell into this trap:
“As a customer, I can post a recurring shift”
Seems innocuous enough. But the user story does not actually state what the need is. What does a recurring shift do? Why is this a need when there was already a previous solution in place called “multi-day jobs”? Although this initial story was clear to the product manager who wrote it, after kicking off the initiative the engineering and design team members had lengthy questions about how to define a recurring shift. After discussion, the user story was re-written to more accurately reflect what the user need is:
“As a customer, I can post a job that repeats according to a shift schedule”
This story illustrates what the user needs to do but avoids referencing the "recurring shifts" solution.
Trap 3: including why the user has the need
One of the most common issues I see with user stories in the original format is that there is ambiguity in what the need is. Specifically, if the need is in the initial statement or if the need is after the “so that” connector. Let's look at this example:
“As a user, I need a dashboard so that I can understand my business at a glance”
This likely seems fine to the in-experienced. But if you progress with this structure you’ll eventually have your design lead ask why you’re dictating a dashboard. Couldn’t alternatives exist? As you go around the team you’d find dissent on if the need is a dashboard or understanding the business at a glance. When you engage in a discussion, you'd find that actual user need is “understand my business at a glance”, whereas the dashboard is a possible solution. Given this, a simpler alternative is:
“As a user, I need to understand my business at a glance”
This simpler format highlights the need and moves the possible solution to the Considerations section.
The key to it all: The Considerations section
As you work to make your user stories more succinct, you’ll still need a way to organize ideas, thoughts, and open questions for the PRD. Taking the last example, if research returns users asking for a dashboard, this should be included in the Considerations section. The Considerations section is where you can add your potential solutions that you've uncovered along the way. To reiterate: potential solutions are good content - but it's not part of the problem - it’s part of the solution. Separating the problem from the solution is what makes or breaks the kickoff of a project. And making sure that your user stories succinctly summarize the problem is the key to success.