User stories are probably the most widely employed requirements-gathering tool in agile software development. The user story captures a description of a software feature from an end-user perspective by describing the type of user, what the user wants, and why:

As a someone, I want to do something so that some result or benefit.

I want to look more closely at the start of the user story. Namely, I want to talk about who that “someone” is.

One of my clients writes software for medical treatment. Like just about every other team, their initial stories began, “As a user, I want …” After awhile, they started to write stories for more specific roles, such as “As a doctor” and “As a lab technician.” A little later, they started writing stories about the ultimate customer: “As a patient, I want …”

Improving their understanding of who used the software led them to see multiple products where previously, there was one. Identifying dedicated products helped them prioritize and accelerate delivery.

“As a User”? You Can Do Better!

Too many user stories begin,

As a user …

These words add nothing to the story. If you see them, delete them. Users are not homogenous. A minor improvement over this is

As a customer …

A customer is a more specific user, but again, they are not homogenous. When I see stories that start “As a user” or “As a customer,” I can’t help thinking that they were written in a hurry and little thought was given to who will actually work with the system.

Always seek to be as specific as possible about the who in a story, rather than targeting a generic “customer.”

Roles, Personas, and Stakeholders

User stories are normally written about roles—the people who would use the system and actually put their hands on the keyboard (or perhaps the touch screen.) As a result, user stories not only lend themselves to a user-centric design paradigm, they encourage one—even when it is not applicable.

Some teams create personas to understand who will use the system. Personas are good; they originated in marketing and were adopted by the user experience design community. Personas bring texture, feeling, and an understanding of your target user. The combination of the words on the story and the persona help teams imagine and empathize with customers.

Personas also narrow the definition of who will use the system and help make the story smaller. But sometimes, it is helpful to go in the opposite direction: to stakeholders.

All personas play a role, and all roles are stakeholders, but not all stakeholders are roles. Stakeholders might have a direct requirement, or they may constrain the system—if that’s the case, write stories that refer to stakeholders.

Some stakeholders will never touch the system. For example, a call center manager may never use call-handling software, but he is a stakeholder. His staff will use the system, and as a result he may have requirements for the system, so you should write stories about him:

As a call center manager, I want new employees to be able to learn to use the system in less than two days so that they are productive as soon as possible.

Unfortunately, because a stakeholder is more generalized than a role or persona, such stories may be larger in size. Watch for this and seek opportunities to redress the balance.

Spending time to identify stakeholders and user roles and create personas starts to add analysis to user stories. Some analysis is useful, but be careful to avoid analysis becoming an end in its own right. While a brief period of analysis can be helpful before development begins, diminishing returns quickly set in. Actually doing some work and looking at the results quickly becomes a faster way to learn.

Don’t Write Stories about the Team

Development team members are not usually typical customers of the software they create, so it rarely makes sense to write stories about programmers, testers, analysts, managers, and others who work on the team. Stories written about team members tend to have a certain “make work” sound to them:

As a programmer, I would like to write some code so that I can get paid for coding.

Sometimes teams fall into the trap of writing stories because there is no defined end-user, customer, or beneficiary. The product owner in particular seems to suffer:

As a product owner, I want the system to take payment from customers so that they can pay for their purchases.

While the product owner will certainly want customers to pay for their purchases, the product owner is not the ultimate beneficiary; he or she is a proxy for the customer. This story would be better written as:

As a buyer, I want to pay for my purchases.

Even if the product owner were in some way the ultimate beneficiary, this version of the story is shorter and clearer. (By the way, if the so that clause is obvious or trivial—as it would have been in the last example, as in, “so that I legally own them”—you can skip it.)

If stories are repeatedly written about team members, it may well be a sign that the product owner and team do not really understand who the customer is, who will use the product, and who will receive the benefits of the system. The product owner may be missing or not doing the job correctly.

Similarly, stories about organization entities show a lack of focus and understanding:

As the business, I want lots of rich content so that search engines will index the site and bring visitors.

As an online shop, we want customers to pay for purchases so that we have some revenue.

As an airline, I want all flight options presented to searchers so that they can book a ticket.

Even leaving aside the grammatical and philosophical problems, it should be clear that each of these stories is vague and overly verbose. But as with other heuristics presented here, there are occasional exceptions. Perhaps the best example of breaking this rule comes from testers:

As a tester, I want to see a log of all user actions so that I can check that the final reports are what was requested.

Such extra functionality allows the team to work more effectively. Still, if there are many stories using this formula, then some questions need answering. Indeed, I consider any story that references the team or the organization building the software with suspicion. Explain the exception or rewrite the story.

Resolve Confusion with Conversation

Better-written stories always help, but if conversations happen around the user stories—as they should—talking should resolve confusion. When conversations don’t happen, greater demands are made of stories and they start to resemble requirements of old. If you find yourself arguing over the words on the card, then you probably aren’t having the constructive conversation you want.