Telling a story: why we love user-stories for requirements capture


User stories are the de facto standard for expressing user requirements and have been for at least 10 years, at least in Agile web development projects. They might be a little informal for air traffic control systems or the US military but let’s not worry about that too much.

For everyday business systems the user story is a great way to express what the user will want out of a piece of software and I want to say a bit about how we use them at SSA and what we’ve learned about using the story in a commercial web build.

The story has a standard form that you may have come across as follows:

As a [type of user] I can [do something] so that [a business benefit is gained]

This is the prescribed form of a user story and although we at SSA like to be quite informal about some aspects of development, we find that strictly following the Agile story format has great benefits.

In fact, the introduction of the user story form transformed and vastly simplified our requirements capture process. Our requirements gathering used to involve a senior consultant chatting with the client for several hours in a completely unstructured way and then writing up a ‘requirements’ document that the client would be asked to sign-off. The documents were even referred to as the ‘Business Analysis Document’ or BAD. I kid you not. And they were pretty bad.

Among the many drawbacks of this approach were:

  • We were totally dependent on the senior consultant grasping the essence of what the client wanted
  • It was impossible to delegate the capture process to a less experienced member of the team
  • We were very reliant on mind-share with the client: the process worked only if there was a close cultural match between the consultant and the client’s use of language and idiom
  • User requirements tended to be polluted with technical detail too early, e.g. data models, because there was nothing in the process to keep the focus on ‘what’ was needed, and away from the ‘how’ it should be done.

Thanks largely to a desire to be more Agile (and Matt’s candid appraisal of our old approach when he joined SSA last year!) we streamlined the capture process to become very simple. All we now do is write user stories collaboratively with the client until both parties agree that the scope is well defined.

It sounds easy, and it is (well a lot easier), and it is also methodical, straightforward and quickly becomes familiar to everyone involved in the project. Incidentally, that is one of the unexpected joys of Agile, that our clients – without exception – have recognised the benefits almost immediately and been very willing to adopt the process and conventions. That’s a lot of company ‘change’ introduced with minimal negative impact – Agile is best practice for a good reason!

So why is the user story such good news? Let’s count the ways:

  1. It puts the reader in the driving seat. It is expressed in the first person so when you read a story you imagine yourself right at the heart of the action and this provokes insight and opinion.
  2. It captures the type of user we are talking about. User roles and permissions (i.e. security) are usually a big part of business web systems and the story contains that information.
  3. It is action-orientated so it feels dynamic. Clients like it because it explains what the software will do, and engineers like it because it expresses a function, and engineers like functions, because they can be coded. So it makes sense to clients and techies alike.
  4. Best of all, it expresses the business benefit of the function or feature – the [so that] part. Why is the user bothering to do this action? What benefit is there to the business? Each story has this little reminder of value built-in. Why are we spending all this time and effort to write this software – ah yes, so that we gain X.

This last point is so important to us at SSA that I’d like to give a few examples of good and bad articulations. It is worth spending time discussing the [so that] with the client so we really get that part written right. There is often a surprise in the [so that] that we may not have appreciated and it is a great way to avoid false assumptions that can lead to implementations that miss the point.

Good examples:

  • As an editor, I can see previous and current versions of the article with differences highlighted, so that the author doesn’t have to call or email me to tell me what they’ve changed.
  • As a data entry user, I can receive an email when the data upload is completed, so that I don’t keep having to come back to the system to check on progress for large upload files.
  • As a sales user, I can send my customer a quote in PDF format, so that the system can format the quote consistently in ‘house style’ and sales people don’t have to spend time trying to format Word documents nicely.

Bad examples:

  • As a super-user, I can add or remove entries from the list of countries, so that the right countries are shown to the customer on the checkout screen.
  • As a moderator, I can edit the text of a forum post, so that offending words can be removed.

These [so that] expressions don’t go far enough in identifying the business value of the feature.

StoryTelling2Better that the super-user can add or remove countries so that ‘the customer can always see the latest list of shipping destinations when our distribution network changes’ and the moderator can edit offensive forum posts so that ‘using the forum is always a pleasant experience and user complaints can be minimised’. Yes, those outcomes sound like they are worth paying for!

So you can see from these few examples that a good user story is just that, a story. It should instantly invoke the image of a real person having a real world issue, and switch on a light-bulb showing how great software will ease their pain.

We find that taking the time to hone these user stories, collaboratively with the client, pays great dividends throughout the project, paying particular attention to the [so that] value clause. Composing a good user story on a shared screen with the client and getting the articulation just right so that the client and the technical team are all nodding and agreeing on the words can create a great rapport and inspires good level of confidence that we are all on the same page.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s