Agile teams write user stories to express the desired business value for many types of product backlog items, especially features.
One common format for user stories is:
This simple user story format helps teams craft well-written stories that business people and technical people can readily understand. Sometimes, however, teams assign goals and benefits to user roles that don’t actually match the intended user role’s true needs and desires. These user stories appear at first glance to be well written but on closer inspection just don’t make sense when read from the perspective of the specific <user role>.
Let me give you an example. Several years ago I was conducting a user story–writing workshop with a company that was building an email system. The system was unique in that it would be licensed to large telecom carriers (like AT&T and Verizon). The idea was that when people purchased a phone from AT&T or Verizon, they would receive a free email account from their carrier.
During that workshop, the team created the following user story:
When I reviewed this story, my first comment was, “Not me. I’m a cell phone customer and I definitely don’t want ads on my email messages.”
The team was confused. “What do you mean?” they asked. “That’s a core story—we have to put ads on email messages in order for the carrier to give away free email accounts.”
I responded, “Yeah, I get that. But, this story doesn’t work because it doesn’t make any sense from the perspective of the cell phone customer!”
I wrote on a new card and handed it to the team, “Here’s a story that accurately reflects the cell phone customer’s perspective:”
After everyone had read the card, I continued. “The story you wrote before just doesn’t make sense from the user role’s perspective! Cell phone customers don’t want ads on their emails (nobody wants ads on their emails!) The story just doesn’t pass the ‘sensibility test.’”
I then suggested that they rewrite the user story from the perspective of the user role that truly gets the value from the story. That story might look something like this:
Now this story makes sense! The user role in the story is the role that actually is getting the value described in the story. The role matches the goal!
As you write stories, stop to consider who the user role is for the specific feature you are describing. Is it your customer or your customer’s customer? The customer of the company developing the email system was the cell phone carrier (AT&T or Verizon). Their customer’s customer was the cell phone customer. Either role is a candidate to be used in a story, as long as the story reflects the correct role’s perspective.
If your backlog is filled with stories where the goal and the role aren’t in sync, it’s probably time to rewrite them.