A colleague asked me this recently. At first, I misinterpreted the question – as in “where do you babies come from?” I quickly realized that she was asking what they represent not under which rock you find them. I wondered how other people had answered this question. If you do some searching, you will find the answers at the top of the list – from respectable sources – are focused on the mechanisms of generating user stories through workshops or activities. They talk about where to find them, or the motions you go through to write them, or the syntactic lint for how they should have been written.
The better sources point out that the card (the container for the user story) is not really the story, but rather a commitment to have a conversation (“to tell a story”). If you really do some sleuthing, you’ll discover that the concept of a user story is intended to assure that people with “problems” converse with the team providing “solutions.”
One of the nice things about ambiguous language (“…come from?”) is that occasionally you can select the interpretation you desire and innocently apply it to answer the question you really want to answer.
The question I believe is most important to answer – if it were not grammatically awkward and wrong – would be “Why do user stories come from?” Really, what we need to know is what are we trying to achieve (for our users), when we write user stories.
- We value understanding the goals of users more than deciding if stories are best documented on physical cards or in a database.
- We value knowing the context in which users face their problems more than selecting a particular syntax (or “sing-song”
- We value developing insights into how users are solving problems more than assuring a multi-disciplinary team brainstorms as the technique for synthesizing information into stories
- We value knowing how users define success at solving their problems more than knowing how we define metrics for the product
The “first principles” of user stories must include knowing what user stories represent, so that they work – regardless of where they are stored, regardless of who is in the room when they are written down, regardless of the syntax used to write them.
To be clear – all of these things are important. They are not as important as the other things.
Understanding the Goals of Users
If we could jack ideas into our heads like Neo in the Matrix, the idea I would be force into your skull is that users don’t want to use your product. Users just want to solve their problems. Your challenge is to get the users to want to use your product as part of solving their problems. An outside-in perspective is where user stories start. The user’s story isn’t “I put the _key_ in the ignition and turned it…” The story begins with “I started the car” or maybe “I escaped the zombies in my car.”
As a user, I don’t want to put my key in the ignition. As a user, I want to go somewhere (or maybe just drive around for a while). That’s my goal. User stories don’t come from an understanding of how the user will use our product. User stories come from an understanding of what the user needs to do.
Compare the following two user stories
- As a parent of a colicky baby, I need to be able to turn the key in the ignition quietly so that I don’t disturb my baby when he is sleeping.
- As a parent of a colicky baby, I need to be able to drive him around the neighborhood until he falls asleep, and get him back into bed without waking him.
With the first story, we will build a nice, quiet ignition mechanism. With the second story, we might avoid having the horn honk – waking the sleeping baby – when locking the car using the remote fob. We at least have an opportunity to think about it.
Knowing the Context in Which Users Face Their Problems
Knowing that our user needs to eat a healthy breakfast is one thing. Knowing that she needs to do it while riding on the train to work because she doesn’t have time after getting her kids off to school, rushing to a morning meeting, is another thing entirely.
Suddenly, oatmeal and a sliced banana is awkward. Simply by adding context, sunny side up eggs become quite miserable as a breakfast solution. A granola bar and an unsliced banana become more appealing.
When introducing new products, they are rarely designed to solve new problems. The problems don’t simply come into existence and demand to be solved simply because our great new product suddenly exists to solve them. What are the users doing to solve the problem today?
A very smart colleague framed risk management strategies as being classifiable as one of avoid, accept, mitigate or transfer. The same type of framing can be applied when competing against non-consumption – a buzzword coming to you soon. Your product is competing with someone who has found some other way to deal with the problem you designed your product to solve.
Your target user could be doing something less-than-optimally (in effect, creating a different problem) in order to “avoid” the primary problem. Eating unhealthy, but convenient fast food to avoid the problems of not eating. Accepting the problems that come from not eating. This is the context in which you have to understand how and why someone might user your product, relative to the alternatives they have available for addressing the problem you hope to solve.
Compare the following two user stories
- As a professional office worker, I need to eat my breakfast, so that I do not pass out at the podium during my board presentation.
- As a harried morning commuter, I need to eat my breakfast during my commute, so that I do not pass out at the podium during my board presentation.
Remember – a story, as written, is not complete documentation of requirements – it is a commitment to have a conversation. “During my commute” is a great trigger for conversation. Why must our commuter eat during the commute? Can she not eat during the meeting?
Developing Insights into How Users Are Solving Their Problems
A key aspect of understanding the context in which a user faces problems is knowing what they are doing to address the problems today. In some ways, this is developing an understanding of your competition – both what they do, and how well the users think the competitors do it. One trap many companies fall into is defining their competition as “companies that look like us” or “companies with products that look like ours.” Tesla might correctly identify BMW as a competitor (working on an electric car), but might mistakenly not consider Uber to be providing a competitive product. [Sidebar: does Tesla solve the “I don’t have a car” problem, or do they solve the “I need ad hoc transportation” problem?]
Your user has a problem, and has multiple ways to solve it. A manufacturer of bandsaws is competing not only with other bandsaw makers, but also hand-saw makers, jigsaw makers, etc. The problem a user is solving is (one of several specific variations of) needing to cut boards. Or, if we’re thinking in a wider context, the user is trying to make a dining room chairs. When thinking about “cutting a board” the user will develop one set of criteria for comparing products – mostly around safety, cost, convenience and effectiveness if tool reviews are to be believed. When thinking about “making chairs” additional factors – the ability to cut joinery and curves – the specific types of cuts needed to create the parts that will be assembled into chairs will also be considered. Very likely leading to a different outcome than generically, horizontally, comparing “the ability to cut stuff.”
The fastest way to get started understanding the universe of possible solutions to a given problem is to assay the common solutions already in practice. You can later identify the weaknesses in those solution approaches, and design a competitive and differentiated product. The ability to differentiate starts with understanding from what it is your product is differentiating.
Compare the following two user stories
- As a woodworker, I need to cut a board, so that I can make fine furniture.
- As a chair-making woodworker, I need to cut mortise and tenon joints precisely, so that I can make chairs that do not rock.
Both stories would have acceptance criteria that articulated accuracy and squareness, speeds and feeds, and constrained the design space to meet safety criteria. The second story would provide insights into the context of usage that may inform prioritization, and will certainly inform design decisions, hypothesis formulation, and user acceptance testing.
Knowing How Users Define Success at Solving Their Problems
When you know the problems your users are trying to solve, and you know what their possible solution approaches are, the next most important thing to know is how they define success. What does it mean for a user to say “I’ve solved my problem?”
- My problem is solved when my device works for at least a week of heavy use (70% of all scenarios) without recharging.
- My problem is solved when I can quickly and correctly make the appropriate decision to accept or reject a loan application.
- My problem is solved when my online shopping order is completed before I reach the front of the line at the coffee shop.
The most important thing to realize is the definition of success is based on what the user is trying to do – and the problems the user is facing, more specifically. Success is not measured by reflecting on aspects of the product. Success for a user is not having a 3200 mAh battery. Success is being entertained for an entire transatlantic flight.
When defining the acceptance criteria for a user story, you are communicating to your engineering team how the user would consider success at the activity the story describes. From there, you can build a test plan that describes how to measure the product you choose to build.
User stories come from understanding the goals of users, the context in which they face their problems, the alternatives they have for solving those problems, and their definition of success.
Where do user stories come from?
User stories come from understanding your market.