Enhancing user stories with the C-word

9 minutes read

The Bugatti Veyron (shown above) isn’t just a fast car, it’s a biblically fast car. With over one thousand angry horses under its bonnet it can go from 0 to 60 miles per hour in less than 2.5 seconds. If the road is long enough, and straight enough it can continue on to a barely believable 254 miles per hour, or 268 mph if you happen to have the Super Sport Edition – Wowzers.

The Land Rover Defender on the other hand (shown below) could never be described as a fast car, or even a mildly rapid one. The horses under its bonnet aren’t angry, just mildly asthmatic, and no doubt very disgruntled at having to haul around what can only be described as a brick on wheels. If you’re brave enough to make it up to 60 miles per hour in a Defender then it’s likely to take you at least 16 seconds, which incidentally is about the same amount of time that it takes a Bugatti Veyron to get up to 186 miles per hour!

It’s plain to see that a Bugatti Veyron is in a very different speed league to the humble Land Rover Defender. If the Bugatti Veyron is a hare, then the Land Rover Defender is very much a tortoise. I wonder then, like the fabled story of the tortoise vs the hare, if you were to race the two, which do you think would win? Easy I suspect you’d say – the Bugatti Veyron would win every time. How could it possibly lose to a car that was designed over fifty years ago?

Well you’d think so wouldn’t you? But what if I were to tell you that this was an off-road race? A race run on mud, rather than tarmac. What if I were to change the context of the race? The Bugatti Veyron is a phenomenal car, but driving off road is certainly not one of its party pieces. A Defender on the other hand is arguably more at home off the road than on it. An off-road race would see the sure footed Land Rover Defender running rings around its super car cousin. The tortoise would once again trump the hare.

Our hypothetical race between a super car and an off-roader is a great example of the importance of the C-word. Not the naughty one, but the one beloved of designers everywhere – CONTEXT. The what; the why; the where; the who; the when.

You see context is pretty damn important when it comes to communicating things. From hypothetical head-to-head car races, to requirements in the form of user stories, context helps, well to set the context. Without this information there is the danger that important details are missed. That we end up building a Bugatti Veyron, when really we needed a Land Rover Defender all along.

Context is crucial to communicating requirements when designing and building something, but it’s all too often lacking from something that we have increasingly come to rely upon to help communicate those requirements – user stories. Those ‘As a … I want to … So that …. ‘ nuggets of information that are used by Agile teams across the globe to help slice and dice work into bite-sized parcels of user functionality.

I’m going to show you how to use the C-word (CONTEXT, not the naughty one) to enhance your user stories. I’m going to show you how to add that all important context, so that you can ensure that user requirements are accurately communicated. Before I do so, I want to outline what I see as the problem with user stories as they currently stand.

The problem with user stories

User stories are now synonymous with the increasingly popular Scrum flavour of Agile, but they actually came out of Extreme Programming (XP), an earlier form of Agile software development. Extreme programming suggests that, “user stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customer’s terminology without techno-syntax.”. In other words ‘user stories’ are just that – little stories about what the product needs to allow users to do. They don’t have to follow some set format, just need to be short and written in non techno-babble.

The problem is that somewhere along the way user stories became the formulaic beast that we see today. Teams try to squeeze their requirements into succinct ‘As… I want to… so that…’ sentences, and in doing so lose the essence, and certainly the context of those stories. You see something like:

“As an editor I want to open a document so that I can make some changes”.

On the surface of it, this looks ok. We have our users (editors), we have our functionality (opening a document) and we have our user task (making some changes). But the problem is that this is very little information to go on. The user story is missing that all important context. Exactly who are these editors? Are they likely to be experienced using this product? What sort of device are they likely to be using? Where and when might they be doing this? What is their motivation for making those changes? These are the sorts of questions that any Agile team worth their salt should be asking, and information that ideally should be contained within the user story. Sure this information could be attached to the user story, but really you want it as part of the user story. Otherwise that extra information all too often gets lost along the way.

In my opinion the current user story template is a little too succinct. One of its key strengths, is also its key weaknesses. It lacks key contextual information and is all too often very open to interpretation. So how can we add this contextual information without making the user story template too bloated? Let’s have a go shall we.

Providing context for ‘who’

The current user story template gives some clue as to who the users are, but all too often the label used is very non-descript. For example, ‘editors’, ‘admin users’, or the super generic ‘customers’. Users are reduced to a homogeneous group, with next to no contextual information provided. Fortunately help is at hand because a very useful UX tool exists that can provide just the sort of contextual information that we’re craving – personas.

I’ve written before about how great personas are (see Why there is still life left in Personas and Getting the most out of personas). Personas (such as the example above) are simply fictional representations of your users. They are fictional, in so much as you wouldn’t typically use a real user as a persona, but are very much based on fact. For example, you might have a persona outlining the characteristics, needs and requirements of editors.

Personas help to communicate all those important details about users to the team. The sort of considerations that are key to designing a great user experience. By referencing a persona within a user story the team can be much better informed about that set of users and their likely context of use. Once we have some personas, we can add a reference to them within the user story:

As a [type of user] like [persona]…

Our original user story might therefore become, ‘As an editor like Margaret…’, where Margaret is a persona for the editor user group. Of course if you don’t have personas, then you can’t add references to them. However, as I outlined in my Minimum Viable Personas article, creating personas is not only a really invaluable exercise, but can be incredibly quick and easy to do.

Providing context for ‘where’

We can use personas to help provide some context for ‘who’ the users are within a user story, but what about ‘where’ they are? An environment can have a huge impact on a user and their interactions with a product. For example, is it a noisy environment? Is the user likely to be interrupted? Is the user indoors or outdoors?

We can include this important environmental context by adding a little extra information to the user story template:

As a [type of user] like [persona] at [environment],

For example, our original user story might now start as:

As an editor like Margaret at work…

This lets the team know that our Margaret like user might be at work, so he or she might be able to ask for help if they’re struggling to do something. It also might mean that he or she might be distracted part way through their task, perhaps by a phone call or by someone calling by their desk.

Providing context for ‘what’

The current ‘I want to …’ part of the traditional user story template gives a hint as to ‘what’ the user needs to be able to do, but rarely mentions ‘what’ the user is using to do it. Digital products can be accessed on an increasing number of devices these days, from laptops, to desktops, mobiles, tablets and everything in between. Even if ultimately a feature needs to work across a range of devices it can be useful to specify a particular type of device within a user story. This helps to establish the context and to get the team thinking about considerations for that device, such as touch screen vs mouse.

We can include this important ‘what’ context by adding a little extra information to the user story template:

As a [type of user] like [persona] at [environment]. I want to [do something] using [device] so that [reason for task]

Our user story might therefore become:

As an editor like Margaret at work. I want to open a document using my work laptop so that I can make a change.

We now have even more context for the user story. We know that our Margaret like user is at work and is using their laptop computer. He or she is likely to be using a mouse, or track pad, and might even have multiple monitors. These are all important considerations when it comes to designing and evaluating this user story.

Providing context for ‘why’

Our last addition to the user story template concerns the ‘why’. Why is the user trying to carry out this task in the first place? This is subtly different from the ‘so that…’ part of the user story because this usually just concerns the motivation for the task, not the user’s overall goal. For example, we might learn that editors need to quickly open and change documents so that an article can be published. This important information wouldn’t be communicated if we just said, ‘…so that I can make changes to a document’. The ‘why’ also helps to frame the user story within their wider journey. For example, we can know that opening a document is part of the wider goal of publishing a document.

We can include the ‘why’ context by adding a final section to the user story template:

As a [type of user] like [persona] at [environment]. I want to [do something] using [device] so that [reason for task]. This will [user goal].

For example, our user story might finally become:

As an editor like Margaret at work. I want to open a document using my work laptop so that I can make a change. This will help me to get the document published.

We now know an awful lot more about the context of the user story. The team is in a much better place to design, evaluate and ultimately deliver that feature because we now have a story about users, rather than simply a user story.

The updated user story template

We’ve added the ‘who’, the ‘where’, the ‘what’ and the ‘why’ to our user story template. Our template has now finally become (drum roll please):

As a [type of user] like [persona] at [environment]. I want to [do something] using [device] so that [reason for task]. This will [user goal].

In our example user story, we have gone from something that is very open to interpretation:

As an editor I want to open a document so that I can make some changes

To something which provides a lot more context:

As an editor like Margaret at work. I want to open a document using my work laptop so that I can make a change. This will help me to publish the document.

Do you notice something? We now have 3 sentences, just as the Extreme programming guidelines suggested. We have an actual story about users, rather than simply a user story.

Of course by its nature Agile is flexible. Don’t feel that you have to include everything in your user stories, and certainly don’t feel that you have to religiously follow the template. For example, if you’re only designing for one particular device, or one particular environment then you might not include these details as they won’t change from story to story. Have a go using the template and let me know how you get on using the comments below. I’m sure that you’ll have a great story to tell…

Image credits

Bugatti Veyron by M 93
Land Rover Defender by Shelka04