The user story is one of the useful initiatives that came out of the Agile movement. It expresses a very specific user need. Usually it’s written in just a few sentences in the language of the users. So any user and developer should be able to read a user story and immediately understand it.

User stories gained popularity after realizing that developers had to start working with users throughout the project to understand their needs. It certainly works better than letting a developer discuss the needs with a user, which tends to end after a few minutes in a “Yes, I get it! No worries, know what you need”, followed by a near endless code-and-fix cycles.

So user stories are great, but who writes them? Hmmm, users probably. After all it’s their story. Question is “can users write user stories”? The answer is simple: it depends….

Certainly some users can write user stories. Sysadmins can, helpdesk and application support too. But the “real” users, can they write user stories? I don’t know about that. When you leave the writing of user stories in the hands of the users that can write user stories you may end up with “unbalanced systems” like the ones in the famous what-if-airplanes picture. After all, you don’t build a system just to do application support or system admin (unless that is your business). You build systems to increase “business value” or whatever greater purpose and for that you need the “real” users.

As stated before: “any user and developer should be able to read a user story and immediately understand it”. If it is that simple, it cannot be too hard to learn how to write a user story.

A user story consists of two parts:

-Just a few lines of text that describe the problem;

-A Test that serves as an example and that can be used to determine when a story is complete.

A simple template for this can be found here: cukes.info

All very simple, and I bet it is possible to make a training course with exercises were the stories and their tests just drip of the table….

Unfortunately, most systems we build nowadays are not that simple. Recently I explained user stories to a group of barristers who were asked to describe their new system. After the theoretical part it was time for some their first user story. Not some lab example a real life one.

Barrister: how do we start?

Me: just go over the things you do during the day and see where your new system system comes in

Barrister: I visit people with a legal document, hand it over, explain the implications and sometimes I give them advice or propose a solution. Then I make notes on their file. That’s it.

Me: Hmmm, that is too simple, there must be more…..

The discussion continued for quite some time and finally we found that the user story was about efficiency. In the morning they receive a pile of documents for that day, they order them by address, program their navigation system and they make their visits.

Or the cukes.info template:

In order to make as many visits as possible during a day

As a barrister

I want to receive an daily workload optimized for traveling time and in such a way that I spend the least possible time in programming my navigation system.

Barrister: not in a million years I would have come up with this user story! And how do I write a test for this? Is the navigation system part of the whole system? And what if there are traffic jams or rush hours should that be in there too? And what about different makes of navigation systems?

My conclusion: help your users in writing user stories and certainly help them in writing test scenario’s.