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.