So what!

I’ll start off by saying at what point I believe user stories should be introduced.

Whilst it differs from project to project we are currently discussing at what stage this should be.  

I am of the firm belief that they should be introduced after the prototype has been created. Now that is not to say that there can’t be any initial user stories created when in the first UX workshop, but I feel that there needs to be something that we can reference off when creating the full list. If you can go through the prototype page by page you can reference or label the page number against the ticket which will come in handy when working out what to prioritise in design and development. It also leads to less mistakes if you run the risk of leaving anything out.

With nothing to go off but ideas in our heads, making sure we get all the user stories thought of and documented is much more difficult with no reference point. That being said it’s not impossible. Some people prefer it this way, and would rather the prototype get based off the stories themselves. Maybe the client has such a detailed brief that it’s easy to document all the requirements up front. More often than not though – and I probably have my views because I work with a lot of start-up websites – it’s not until the rapid prototype visualisation stage that we get an understanding of the flow and what we will offer users of the site.

Therefore I believe the client needs to see something visual before they can start discussing and thinking about what functions are specifically important for each page of their site.

There are lots of functionality areas that are difficult to forsee especially around how they will work until you have a prototype and process flows in place.

So this brings me to my next point….the user story template. For those that don’t know the template, I have it below:

As a [user role], I want to [function], so that [benefit]

What I want to talk about is whether we need to use the ‘so that’ part at the end of the user story. The purpose of including ‘so that’ at the end is to evaluate the importance of the story itself and ultimately decide it’s benefit. This makes it easier to work out what’s actually needed or if it's a nice to have. It forces us and the client to ask if it will it impact the user’s experience if it is or isn’t there.

An example of something with high importance would be:

As a user, I want to pay via credit card online, so that I can pay instantly for my purchase.

By stating the benefit it makes it easier to evaluate when working out essentials and priorities.  

However if it was a user story like:

As a user, I want to see approximate prices in other currencies, so that I know what it would cost in a different country.

The benefit for this wouldn’t be as important as something like credit card payments, so this could be an example of a user story that could possibly be de-prioritised.

It doesn’t only work for prioritising stories, but it can also help to encourage MVP. By stating the benefits it allows clients to instantly evaluate the importance of the story to see if this is even essential in Phase 1.

If user stories were to be created up front, without any previous reference point like a prototype, then yes this could come in handy when working out what to include in the project build.

But do we really need it?

To me? No.

Even for projects that create user stories prior to the prototype, I feel that benefits can be discussed rather than having to be part of the story itself. I see it as a bit of a useless addon. Whilst it does force clients to think about why they really need it, this could easily be discussed during sprint planning meetings or during the user story creation workshop itself.

For projects, where user stories are created following the prototype, to me, the benefits have already been discussed. The process is simply documenting what needs to be built from previous discussions in order to start the development planning. A developer won’t care to look at a benefit when working through the stories. They only see the user role and the function.

To add to this, a lot of the time the benefit is already obvious. With my credit card example the benefit to me is clear, and I think it would be clear to the client as well. For anything that’s not, it can easily be discussed.

So to summarise, I feel that the ‘so that’ part can be left off. It will save time and keep stories more brief and succinct.