User stories – so what?

Time is all we have. And at work – where people pay us for our time – it is also someone’s money. We should use it wisely.

If you make products or services, here’s a surprisingly simple way to get more from less.

All you need to do is remember two little words: so that.

The back-story

User stories became a thing in 2001, during the emergence of agile development. They helped cross-functional teams (in the software domain, a heady mix of testers, BAs, and coders) avoid the pitfalls that previously plagued software delivery.

More recently, the disciplines of IT and design have removed their blinkers and established common, more fertile ground. (Mr Agile, meet Ms Lean – I think you’re going to get along!). User stories have become key to a more holistic, user-centred approach that increases the probability of delivering great user experiences.

We've moved to a broader, healthier definition of cross-functionality in which user stories anchor everything and everyone – through research, design and the delivery minefields – in the actual needs of the people who will use the service. That’s a lot to ask. They need to be robust to survive this hideous journey.

So how you write them seems fairly important. You can get it wrong. And while it can seem a little prosaic there is power and even beauty in a well-written story.

Three is the magic number

Most people will recognise the first two components of a story – a user, and a need that they have:

As a… user of a service
I would like… something to be possible

We describe needs not features, to avoid getting drawn into a specific solution too early, so:

I would like… to access private information securely

Is better than:

I would like… to enter my username and password

Yet generative user and business research can throw up hundreds of hypothetical needs and of course not all are equal. That shiny feature that you see on every competitor’s site might be a solution in search of a problem. Choosing what not to invest in as important as what you do, and it can feel overwhelming. Where to start?

To prioritise effectively we need a sense of what matters most. User research can tell us that.

However things tend to go awry when they scale up. This will happen in an end-to-end delivery process if people on any stage of the critical path fixate on what and how, without understanding why. It happens all too easily.

Your wireframe annotations might as well be written in invisible ink – they will fade from view the further into production you get. Successes happen locally rather than contributing to wider objectives. You lose the ability to flex and still deliver on time, or you prioritise things that fail to make the required impact before the money runs out.

User stories are more likely to stay visible and stimulate important conversations. This is where the third, heroically undervalued component can save the day:

As a… user of a service
I would like… something to be possible
So that… I can get some benefit

Or in our example:

As a… user of a service
I would like… to access private information securely
So that… I can avoid getting robbed or humiliated

Don’t skimp on the so that. Take the time to think it through, boil it down to its essence.

When everyone understands the why, it gives a team focus and confidence:

• Designers and developers can have productive, pragmatic conversations about what’s good enough so that you focus on the most important things
• It avoids circular conversations about edge cases and the horrors of design by committee
• It gives you license to think creatively about the actual need – to look at problems from a different angle and solve them in an original way

You can deliver work with more impact.

A real world example

Let’s say we’re a not-for-profit, delivering essential services for, yes, gnomes. But this is a serious blog; let’s focus on the needs of the common-or-garden gnome as opposed to the discredited, underpant-stealing, lunatic fringe movement.

Our discovery work has generated a bunch of user stories like this:

As a gnome
I would like to be able to choose from range of underpants each morning

And this:

As a gnome
I would like to be able to securely store my underpants

User stories describe user needs! That’s great because we are user-centred people. And these aren’t any old hypothetical needs: firstly, they came from empirical research; secondly, we’ve already explored the problem space using Design Thinking and validated our Alpha-level solutions with participants carefully selected by our favoured gnome-first recruitment partner.

We could totally take these stories into Beta production.

But we only have limited time. What’s really the most important thing we could do for hard-working family-gnomes? What would deliver the most benefit?

Let’s lay down the so that component:

As a gnome
I would like to be able to choose from range of underpants each morning
So that… I can choose from range of underpants each morning

Not too convincing. Maybe it’s not that important after all. Is there anything more in the research?

As a gnome
I would like to be able to choose from range of underpants each morning
So that… I can express myself through my choice of underpants

Ok, but I have to say it feels a bit bourgeois. Self-actualising gnomes can look after themselves – we’re here to provide services on lower Maslovian tier and should probably prioritise something else. How about this one?

As a gnome
I would like to be able to securely store my underpants
So that… they don’t keep getting stolen by the underpant-stealing, lunatic fringe gnomes

And with that we just set ourselves up to deliver more impact from the next release – we’re really confident that we’re going to make something of practical value to our users, and also deliver on our organisational goals. Even the hardest-hearted T-shaped practitioner can relate to that too, so we just increased operational empathy by some percent.

There are many hurdles to overcome before we can make this a real service, and many ways we could meet that need (which means lots of of opportunities to veer off track). Lots of people will need to become involved, with their ideas and that.

But it’s going to be OK because we rationalised so that into our user stories. Whichever path we take, we’re safely anchored in the benefit or outcome we’re trying to create for the user.

Find your own way

There are variants on the so that template. In the entertaining talk from which I stole most of the ideas for this article, David Evans suggests making the benefit the focus of the user story rather than the appendage:

In order to… safeguard my underpants from would-be robbers in my community
As a gnome
I would like to be able to securely store my underpants

We’ve been using this template successfully in recent projects, but don’t get hung up on the format – do what works for you.

What you can do

User stories that lack a well-considered so that component become so what? stories that will result in poor decisions and wasted time. But time is all we have.

Check that your stories clearly describe both a user need and the benefit of meeting that need. If some don't – and you can’t clearly articulate that benefit – then weed them out and double down on the details that will make a difference.