Agile is about being fast and flexible at delivering value, but that doesn’t mean that you shouldn’t care too much about writing User Stories. The description you’ll add to them should not only enable communication and constructive feedback but also motivate your team. Within this article, I describe what are the common pitfalls while writing a User Story and how game designers have understood this better than companies so that you can apply these gamification techniques to it.

Writing User Stories

The Theory

According to Wikipedia (which refers to several sources), a User Story should be written following a pattern, for example (they are all very similar):

“As a <role>, I want <goal/desire> so that <benefit>“

You may think that Wikipedia and that article is not really the first page that a normal human being will use to learn how to write User Stories since they will read much more about Agile before putting it into practice. Well, maybe you shouldn’t have so much faith in humanity, but anyway let’s visit the mountaingoatsoftware.com website since that is a good reference. You can read the pattern given in the FAQ section about user-stories.

Great! It’s really similar, so now we know everything. Let’s start writing User Stories. Or wait, let’s review some examples before that.

The examples

First let’s check the first examples in Wikipedia, same page as before:

Search for customers
As a user, I want to search for my customers by their first and last names.

Modify schedules
As a non-administrative user, I want to modify my own schedules but not the schedules of other users.

Run tests
As a mobile application tester, I want to test my test cases and report results to my management.

And now let’s have a look at the ones in MGS, in the FAQ section about examples.  As of today, they are examples of a backup service.

Do you miss something?

As you can see in the examples, it’s really common to forget including why we are trying to accomplish that task. It’s so common that even in reference pages that part is not there. Then, a curious team member could ask some questions:

• Why you, as a user, want to search your customers by their first and last names? What is the advantage that you’ll gain with that? Are you saving time, maybe compared with what you have now?
• Why does an application tester want to test their test cases? (I’m being sarcastic here, that example is brilliant!) Reporting results to management are the main goal of testing? Why management want the reports?
• Why would a user backup the entire hard drive? What’s the advantage? It’s pretty obvious but even with the most obvious tasks we could be missing something: is it because they don’t want to lose their personal data? Then let’s avoid saving some other stuff.

As a side comment, being curious or inquisitive is usually good, as long as you avoid trolling the Product Owner and your team 🙂

Why is the reason so important?

Saves time and money

In my personal experience, I’ve seen many times a user story being rejected at Sprint Planning time or during refinements, and some others being delivered and then nobody uses the new functionality.

Let’s start with the last one: functionality not being used. There could be many reasons for that, but they normally materialize in a badly written User Story. If it’s not providing any value it’s because the need was not correctly analyzed. These kind of stories are making the company waste money and resources.

On the other hand, the user stories being rejected any time before the Sprint starts must be seen as a success. Actually, the sooner they are rejected the better. Usually, they are rejected because someone is reading the reason why this needs to be done and comes with a better solution. Sometimes is as simple as the requested functionality is already there, but the user should follow different steps to accomplish it.

Every time you use the reason/benefit/business value to enable discussion and improve/reject/simplify the User Story, you are making money for the company. 

Boosts Motivation

Looking for ‘alienation software industry’ I’ve found exactly what I was looking for. Have a look at the slides, mainly the ones starting at 15, they are self-explanatory: Theory of alienation in the software industry.

The key sentence here is:

A Developer is not a code producer but a problem thinker.

Some companies tend to see developers as machines. They’re given some instructions and after some time they manufacture the products the company needs. This should be only happening in companies working with waterfall style, but the truth is that is also happening in companies following Agile and Scrum practices.

And the reality is that, as many other professionals, developers are smart and creative. With enough motivation, they can make a company much better.

And what is the relation between this and writing a good user story? If you don’t clarify the reason behind that task, people will get alienated: they don’t know who are the users, what are the problems they’re trying to solve, how much money or time they are saving to them.

The problem about writing software is that it is not like fixing a car: it’s intangible, you don’t see the result. Business cases are usually complex and for a developer is really common not to know the user or even see the entire platform working. That demotivates people: they don’t really know what they are doing.

Writing good user stories

Now that you understand the importance of the ‘why‘ let’s rewrite one of the user stories above so it helps to motivate people and encourage discussion:

Search for customers
As a sales user, I want to search for my customers by their first and last names. Right now I can only search in a list and having that extra search ability will decrease the duration of my phone calls, which will lead to an improvement in user satisfaction and also will increment the total number of users per day that our department can handle with the same resources.

Some of you may think it’s too long, it’s not one sentence… I’m not an Agile purist so I still prefer this version 🙂

How can this helps the company to motivate people and earn more money?

1. As a software developer, I feel like contributing to something. Now I see the problem and what will be the outcome of that task. It’s more tangible.
2. As a company, I’m enabling discussions. In this case for example:
   1. “Oh, it’s about time! We could include a brand new component for auto-complete fields that shows matches with custom fields and keyboard shortcuts, so the sales person can decide between matches by entering a number instead of going to the results table.”
   2. “If it’s about time, why not including phone number instead? I know this is a unique key in the database and numbers are easier to tell via phone.”
   3. “Actually the phone number feature would be really easy to implement since we already have something similar.”

The outcome of the conversation in 2 may be solving the problem much faster than expected, and searching for a customer will be even better than with the first proposal. The PO can confirm with users if this solution is also acceptable. Actually, it was not about having a cool first name and last name fields, it was about solving a problem and adding value.

Adding the goal, the business value, has changed this sample story. You can see this as an exaggeration or not, it may depend on the teams you have worked.  In my opinion, it’s a cheap investment for the outcome it produces: money, motivation, reconsidering priorities, etc.

Only by enabling these conversations you will make people more motivated, engaged with their work. But imagine if after some weeks you show them how useful this feature was and the metrics of the time that the users are now saving. Cool… Now we have feedback, and you are making people happy and engaged because they know they’re really contributing.

How games and user stories are related?

Finally, as promised, let’s have a look at Gamification and Agile together. And when I use Gamification here, I’m talking more about how to introduce in Agile some common-sense-approaches to boost motivation used in games for many years.

Game designers know how to motivate and engage players. There are many techniques to accomplish that, but among them, you can find:

• Defining a clear goal.
• Give the players a sense of progress.
• Provide fast and valuable feedback.

A good book about this is Reality is Broken, from Jane McGonigal. She uses as an example of a well-written task the video game World of Warcraft, one of its quests:

Of all the times to have such rotten luck!

My tournament blade has gone missing. I’ve heard the bards telling tales of travelers offering winter hyacinths to a lonely maiden in return for gifts. Those hyacinths grow only on the ice flowing from the Ironwall Dam, on Crystalsong Forest’s northwestern border with Icecrown. Gather the flowers and take them to the circle of lamps in Drak’Mar Lake in northeastern Dragonblight, near Zul’Drak and Grizzly Hills. Ask the lonely maiden for a worthy blade.

Is really interesting to see how all ingredients that you would need for a perfect user story are there, just try to find them:

• What’s your goal
• Why it’s important
• Overall instructions
• How to prove that it’s done (and that will provide the feedback)

Can you imagine this quest written like this?

Go to the Crystalsong Forest and gather some flowers. Then take them to Dragonblight.

How boring!

Conclusion

Let’s start writing user stories as if they were quests. Or at least let’s include what is the value, enable discussions, and eventually provide feedback about the value achieved. That will benefit both company and employees. 

If you’re a developer and you’re interested in gamification you might like my book: Microservices – The Practical Way. In it, I include a gamification microservice to motivate users through points and badges.