As anyone who makes things for a living will attest, there comes a time perhaps once a day, when a certain question plays upon the lips of everyone on the project. If it’s a particularly trying day, this question will pop up a few times, and if it’s a doozy of a day, it will be flavoured with a peppering of FFSes and at least one WTF.
The question, my friends, is this:
Why are we doing this?
If you’re using them at all, user stories are a good place to find the answer. These little wonders are a fantastic tool for keeping product teams focused. I would go so far as to say that every team should be using these little gems, regardless of the project management and development methodologies you’re currently using.
The reason is this: user stories, when correctly written, serve as a very visual reminder that whatever you’re working on, with any luck you’re doing it to improve someone else’s life.
By phrasing our plans in the context of another person’s life, we can understand both what we’re doing, and why. And given that the user story provides a start and steer for the conversation around solving that particular problem, we can determine whether or not there is any value to doing it in the first place.
What makes a good user story?
The best user stories are the simplest, where the information you need to know is communicated as efficiently as possible, in the right order. Think of it as the pyramid model of story-telling, where you start with the most important fact and then broaden in scope as you go to give you more of the bigger picture.
The template for the standard user story is something like:
As a [persona/role]
I can [do this]
So that [I get this benefit]
Get that right and you can then figure out the acceptance criteria, i.e. the way that everyone knows the story is done. But how do you find out the bits that go between the brackets?
Hunting the meat of your story
In an ideal scenario, the customer is actively involved in creating user stories. If your project has a formal requirements gathering process, this is the point at which you would usually run a user story session.
If you’re lucky enough to have a business analyst on the team they’ll be the one compiling the stories and cross-checking them against the requirements. A good BA is worth their weight in Percy Pigs for this alone.
A more likely scenario on smaller teams is that this responsibility will be shared between product manager and UX or whoever else is well-placed to pick up the baton and run.
But what if you want to bring user stories in on a project that still uses a waterfall approach? There are a couple of tricks that work well in tandem with the requirements gathering phase of a waterfall project.
I’ve seen both of these employed to great success when working with a large financial services client (and boy, do those bankers love their requirements itemised by the armful in Excel spreadsheets!)
Trick 1: The Parrot
If the only way to involve the customer in creating the user stories is through discussion while you’re working through the requirements, then it’s worth adopting a very simple conversational pattern to make sure everyone is communicating clearly and understands what’s being agreed as being in scope of this project phase.
The trick is quite simply to phrase your questions for the customer in the form of a user story. For example, let’s take a requirement as it would usually be phrased:
“Allow customer to confirm/reject payment before sending.”
You can then rephrase this as:
“So, the customer should be able to cancel the payment, to safeguard against paying someone by accident?”
If the customer responds along the lines of: “Yes, and also it saves us the administrative cost of having to refund that payment,” you then have everything you need to write a compelling user story that has both user and business goals at the heart of the story.
It might seem like this back-and-forth exchange would get tiresome if you’re discussing a requirements doc line by line. But in practise, it actually coaches the customer to think in terms of the reasons for the requirements. Before long, the session naturally flows from a stilted reading of requirements to a more flowing discussion along the lines of “Do this because this”.
This is especially critical if your client is internal, – i.e. your development team works on the company’s product and the client is your managing director or board of directors.
Trick 2: The Path
This approach to creating user stories will work well for the UX or product team of one. Once again, the scenario is that of having to deal with a requirements discussion with a client more used to waterfall than to agile.
Our hero, a young UX with little BA support, turned what could have been a session of death by a thousand lines of requirements into a more engaging and productive session all around.
He read through the requirements ahead of the session and drew up a few user journeys that covered all the scenarios that the requirements pointed to.
In the session, instead of sitting down to discuss the requirements line by line, he put the user journeys up on the walls and kept everyone on their feet. Together they walked the length of the journeys as he pointed out the requirements covered off by each part.
A dozen or more user stories fell out of that process, with the added benefit that it also brought the project to life for the stakeholders.
Any other tips?
If you already use personas, it makes sense to put your personas at the heart of your user story. As Leisa Reichalt discovered, this helps keeps your personas current and active, and often acts as a silent validator of those personas in the first place.
Remember, the user story is about defining problems, not solutions. If your user stories make mention of how you’re going to solve the problem, this immediately limit your team’s ability to approach the problem more creatively. Keep it loose, keep it lean.
For more user story tips, Mike Cohn’s excellent blog can help you construct user stories.