I'm a big fan of user stories for tracking upcoming work. They keep us focused on the problem, not the solution. They're good at reminding us why each chunk of functionality is valuable. Done well, they're easy to prioritize and plan with.
But one of the big issues I have with them is that it's really easy to lose the "user" in the "user story." I've seen way too many projects with several dozen stories that all being "As a user, I want...." The placeholder "user," used over and over again, is usually indicative that we've stopped thinking about the actual users at all, and we're just putting it in for the sake of form.
Which is a shame, because thinking about who we're delivering value for is really important for us to write good stories. So I'm going to talk about a few ways to break out of the rut of constant "as a user..." stories.
Users are not actors
One mistake I see frequently, especially with people transitioning from a use case heavy background to user stories, is to mistake the "As a..." clause of a user story as a place to identify an actor - the individual who is PERFORMING an interaction with a system. But user stories are much more about stakeholders - the individual who gets VALUE from a feature.
In many cases, these are the same, but they need not be. Even though a "user" of the system might be the one interacting with it, something is happening that delivers value for someone else. That's the person who "wants" the feature we're providing. (By the way, I think the term "user story" is a slight misnomer for this reason).
For example, let's say we're building an e-commerce portal, and we have a prospective feature validate a credit card number is a valid number (e.g. by running a checksum) on the client before we submit the credit card transaction for approval to the credit card processor. This is a useful thing to do because many credit card processors charge by the request. If we can figure out on our own the credit number is bad BEFORE we submit the request, we save money - we don't need to incur the expense of a transaction to tell us the credit card didn't go through.
I could write a story for this like "As a user, I want to know that I entered a valid credit card number before I'm allowed to submit my order, so that I can fix the card number if it's wrong."
The problem here is that, while the "user" (a customer in this case) is indeed the one who entered the number, they probably couldn't care less about having an intermediate check between "I clicked submit" and "the transaction was sent to the processor." Heck, they might not even notice it. From the "As a user" perspective, this story is close to valueless.
However, the feature is NOT valueless. Given miskeyed credit card numbers are a major cause of credit card transaction failures, doing an internal check here can cut down a lot of our "waste" of paying for failed credit card transactions. Let's re-write the story from the perspective of the person who actually gets value from this feature.
"As the accounts payable manager, I want credit card numbers pre-checked for validity before they're sent to the credit card processor, so that I don't pay transaction fees for transactions I know will fail."
Suddenly, we've transformed the same feature from a "why would they care?" into a much more compelling story that clearly relates to business value. And it's a lot easier to prioritize this against other stories. If we only have 10 failed credit card transactions per day, this might still not be high value. It we have 10,000 failed transactions a day, this might pay for itself in a week.
"Accounts payable manager" might not be a "role" in the system. Heck,
the accounts payable team might never use our system directly to do
their jobs. And they're certainly not the ones who are actually
entering the credit card numbers. But they're the ones who care about this feature - they're the ones paying the cost of not having it, and the ones who benefit from it being in place. Their perspective is the one that's important when evaluating this story.
A good rule of thumb when putting together the "As a..." clause of a user story is to think "If we took this feature out of scope, who would be first in line to pay me to put it back?"
Users are not system roles
Another way we can lose track of who we're delivering value for is to simply think of individuals in terms of what their "system role" is. We could think about every feature targeted by someone in a "user" level role as "As a user...", and have the features that are only for administrators written as "as an administrator."
This makes some sense from a technical perspective - we're delivering a feature that's intended for everyone who's role in the system is "user." And since we're not intending to restrict the feature to only a subset of users, everyone who's a "user" gets the benefit.
The problem with this approach is that it treats everyone in a user role as being identical. That's rarely the case. For example, think of an online auction site. Everyone who has an account (other than the admins) is a "user" - none are different from a perspective of what they have the ability to do. Anyone can search items, bid on an item, sell items.
But think of the richness that's obfuscated if we just think of everyone as "users." There are lots of subcategories of users that have different perspectives, and different needs. You have power sellers - factory outlets selling many copies of the same item in bulk. You have high-dollar-item sellers, who need lush descriptions and photos to make the item look good. You have online yard sellers, trying to get rid of a few things as cheaply as possible to clean out their basement. You have targeted buyers who want one and only one thing, and want to find it fast. You have browsers who want to compare multiple items of the same general category (such as laptops from 10 different sellers). You even have your day traders, who buy and sell the same items frequently to try and arbitrage short-term market fluctuations.
Each of these "users" might have access to the same tools, but thinking about which one wants a feature can help bring clarity.
"As user, I want to create a template of an item that I want to auction, so that I can later list that item quickly" vs. "As a power seller, I want to create a template listing of an item I have in stock, so that I can create multiple individual auctions quickly."
With the first story, we might wonder why the templating is useful - couldn't we just create the listing directly? The rationale is much more clear when we think about the context of a power seller - the template helps because they can create the "same" auction multiple times. And thinking through that lens clarifies how this needs to work - I clearly need to be able to re-use the template. I may need to be able to change specifics with each new listing (like a serial number). Also, we can probably assess the priority better- how many of our users actually fit the "power seller" profile? Is it worth building this feature primarily for their use?
Users are people
Your users are not faceless anonymous masses. They are (for the most part) human beings. They are people trying to live real lives. In many cases, their interaction with whatever you're building is a small part of their busy life. Often, the thing they're trying to use your system to accomplish is a means to an end (I'm buying this book online so I'll have something to read when I go on my beach vacation).
The problem here, of course, is that every user is different. Trying to write user stories that really capture each user's individual goals, nuance, and perspective is almost impossibly hard for any system that has more than a handful of users.
One technique to try and capture some of this "real user" feel without being able to model real users is to use personas. For those unfamiliar, a "persona" is a somewhat fictionalized biographical sketch of a "typical" user, with more realistic goals. While it's possible to go overboard with them, using personas can bring valuable insight into our implementation of a user story.
Many projects create user personas as part of an inception/exploration phase at the start of the project. It can be very powerful to map stories back to personas. If there's no persona that clearly would use a feature, that's telling us something. Are we missing a segment of our expected userbase in our personas? Or are we devising a feature that no one we think will use the product actually wants?
Let's enhance our user story from the last section by tying it to a persona. Back when we started the project, we anticipated we'd have power users, so we built a persona for them.
Meet Linda. Linda runs her own distressed asset disposal business out of her garage. She has an IT inventory management background, and has contacts with a number of local and regional technology distributors. Linda spends all morning calling around looking for large cancelled orders, unopened returns, and other unwanted tech in bulk. She buys pallet quantities for cheap prices, and sells them off online. The margins aren't great, and she has limited space, so her business is all about speed and volume. She opens dozens of auctions a day, and the less time she needs to spend setting up and maintaining her auctions, the more time she can spend finding great deals.
Now let's try our user story again, this time with the persona as the user. "As Linda, I want to create a template listing of an item I have in stock, so that I can create multiple individual auctions quickly."
We can almost picture this in our mind. We can see Linda sitting in her dusty garage with a laptop, next to an shrink-wrapped pile of LCD monitors trying to set up her auction template. Hey - I bet she wants to be able to pull down the manufacturer's stock description into her auction template, rather than type out a description herself. Hey - I bet she wants some way to track how many of these she has. Hey - I bet when she creates auctions, she's going to want to auto-relist items that don't sell. Hey - you know what would be cool? If she could just scan the barcode on the manufaturer's box and pull all the spec's up automatically....
Some of these thoughts are probably different user stories - we don't want to suddenly drag the mechanism to create and auto-relist auctions into a story to create a template. Even the barcode scanning idea is probably it's own feature that we can add after we build the basic template concept. But keeping Linda and her problems in mind as we build each feature will probably guide dozens of small decisions we make over the course of each story.
It's possible to go overboard with personas. Sometimes we build so many that we lose track - who was "John" again? It's possible to build personas that aren't accurately reflective of the real user community, and so could steer us in the wrong direction (what if 95% of our power sellers aren't like Linda - they're like Charles who works for the distributor and is more interested in recovering the most value rather than turning items at speed?) That said, writing stories to a reasonable set of identifiable personas is a powerful way to keep your team focused on solving real people's real problems.
Software is for built to solve problems for people. Keeping the team focused on who they're building software for, what they want, and why they want it is the key insight behind user stories as a technique, and why they're so powerful.
I don't imagine changing a single word in a user story will take your stories from good to great in a single stroke. The "As an X..." isn't so important as itself. Masses of stories reading "As a user..." are a symptom of a problem, not the problem itself.
What's important is the thinking behind our stories. Are we really thinking about who we're delivering value for? Are we clearly thinking about our users as something other than a uniform monolith? Can we see their faces and breathe their problems? Because that's what makes us great builders of software.