Know Your Customers: They Can Help You Write Better User Stories

Too many user stories begin, "As a user …" Who is your user? Or, more accurately, who are they? Improving your understanding of the types of customers who use your software lets you see multiple products where previously, there was only one—and identifying dedicated products will help you prioritize and accelerate delivery.

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.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.