The user story is a great way to put yourself in the “user” seat and do a reality check for whether what you are planning to build is something the “user” really needs or wants. The user story formula goes
As a [user description]
I [want, need, wish] to [some goal]
so that [some benefit].
Though this formula appears simple, I often see it applied in the wrong way.
For example
As a website visitor I want to enter my email so that I can signup for the website’s newsletter.
In the paragraphs that follow I will try to persuade you that this may not be the right user story and I’ll do it in three steps.
Step #1: Consider all users
“As a website visitor I want to enter my email so that I can signup for the website’s newsletter.”
Is the website visitor the only party that stands to profit from this transaction
The website publisher seems to have something to gain as well. The website publisher wants to collect emails so that they can grow their audience and spread their message, products, and services. It is the website publisher who also has a lot to gain from a signup. It is the website publisher who also stands to profit from collecting emails and it is a story that deserves to be told.
In short, there should be a user story for the website publisher.
Step #2: Select a goal the user really needs, wants, or wishes
“As a website visitor I want to enter my email so that I can signup for the website’s newsletter.”
Do you buy it?
When was the last time you went to a cool new website and, as it loaded, you were chanting “I hope I can sign up, I hope I can sign up,…”. The last time I did that was when Gmail launched and it was an invitation only service (back in 2004).
Entering an email is not a goal, it is a means to an end. The user could hand over his/her email in a myriad of ways, for example through a Facebook or Google login. What the user really wants is to signup for the newsletter, or at least the publisher wants to create the conditions so that the user wants that. By setting a technical implementation as the goal of the user story the story can stifle innovation and creativity. As is, the story anchors the team instead of forcing them to think about the best way to have users signup for the newsletter.
The better story is
“As a website visitor I want to signup for the newsletter…”
The other side of this user story is the publisher side.
“As a website publisher I want users to signup for the newsletter…”
Having a story for both sides helps you see the entire picture and align goals. It will also help in step 3, where you have to select a benefit that incentivizes each side towards their respective goals.
Step #3: Select a believable benefit
“As a website visitor I want to enter my email so that I can signup for the website’s newsletter.”
Why did you signup for a newsletter? Were they giving freebies? Was it a more convenient way to receive updates? Does the newsletters include special offers only available to subscribers?
You get where this is going. These are tangible benefits, the newsletter delivers the benefits, the signup is the first step to unlocking these benefits on a regular basis.
Let’s look at the website publisher side:
“As a website publisher I want users to signup for the newsletter…”
Why would you want users to signup for the newsletter? To lower your cost per order? To have more successful product launches? To bring back stray visitors to your website? Once again, these are very real, very tangible benefits and the best formulation will depend on the business goals of the website publisher.
One more thing
When you have a use case that is two sided, like the one discussed, you should align the stories. Let’s assume that these two are the final user stories:
Website User: “As a website visitor I want to signup for the newsletter so that I can receive special offers and promotions”.
Website Publisher: “As a website publisher I want users to signup for the newsletter so that I can keep visitors coming back to the website to make purchases”.
To align the two stories I use a “Make sure that” section attached to the stories. This section allows you to list additional constraints that you may have for that user story. For example:
Make sure that:
- the user knows that the newsletter includes promotions every [some applicable frequency].
Use user stories to initiate discussions about requirements. The better the stories, the higher the chances are that your team will have more productive discussions about a requirement and think of innovative ways to satisfy the requirement.
Photo by Patrick Perkins on Unsplash