Building Product: The User Stories

14/09/2016

Building Product: The User Stories

There is an old phrase that says, “You will never really understand someone until you walk a mile in their shoes”. And whilst this is often used to encourage people to stop judging others until they know everything about what is happening in their life, it is also the premise behind using ‘User stories’.

By creating ‘user stories’ we can get a good insight into the needs and requirements of a user, as it gives us the chance to see a product from the user’s point of view. They aren’t, as the name might suggest, long sagas, but generally are short, simple and easy to understand.

A user story would usually follow this sort of format:

As a (user), I want (goal), so that (reason).
This could be as simple as:

As a user, I want to be able to exclude certain folders from the back-up so that my back-up folder doesn’t get filled with things that I don’t need to save.

By understanding thoroughly, a user’s requirements, and why, products can be designed and amended to make them as useful as possible.

How to Create User Stories
The first step to creating your user stories is creating your user. This means either collaborating, consulting with your ‘real’ users, helping them to explain to you exactly what it is that they are after, or by creating user personas who fit into your ‘target users’ which will help you to put yourself in their shoes and create accurate and effective user stories. These fictional personas should be given a name and usually a photo to make them seem more real – and ultimately give a more accurate result.

You now need to create your user stories under the format shown above. They should be kept simple, and, most importantly, functional. For example, The software will be written in PHP, is not a good user story, because it is not functional to the user – they don’t care if the software is written in PHP or not, as long as it works!

Most people like to use paper cards to write out their user stories. This is because they are more visual and easier to move around than with a computer programme for example. They also invite collaboration, which is also an important aspect in creating user stories.

Each user story should have a title which can be used to differentiate one from another. Try to keep them as short as possible. If you are having trouble fitting the whole description onto a 3” x 5” sticky note, then it is a sign that the narrative is too long, and perhaps you to break it down further.

You may also wish to include ‘acceptance tests’ which are a set of criteria which can be put in place, which, once ‘passed’, can confirm and highlight to the team to understand what being ‘done’ means. For a detailed user story, normally about three acceptance criteria are put in place. This can then be moved to demonstrate to stakeholders that you have fulfilled your brief and solved the problem which you were given through the user story.

Epics
As the name suggests, an epic is a big, maybe sketchy, more general, overall story. It is sometimes a good idea to start with an epic, and then break it down into smaller, bite size stories which are easier to work with. You can, essentially sketch an overall picture of your user story, without the details, and then work on the intricacies later on.

Once your epics have been broken down into smaller user stories, you can make sure that they are feasible, clear and testable.

User stories can be created at any time as progress winds its way through the twists and turns of any creative project, and you shouldn’t be afraid to add, update or amend anything as you go along.

Prioritising Product Features
Once that you have a list of your product features, it is important to prioritise them to make the project as effective as possible. There are of course certain things that must be done before others can, and your product features can usually be prioritised using the following product feature criteria:

1. Bread and Butter – These are the features that need to be done, in essence, to ‘pay the bills’. You need a product that ensures that the most important features can be done, and these are the bread and butter features, ensuring that the framework is there, then giving you the freedom to embellish and decorate with additional features.
2. Customer requests – These are the more specific user requests which are usually asked for uniquely by the customer, and are essential in delivering the personalised, customer focused product and keep relations between you and the user sweet.
3. Delight features – The delight features are those which are discovered internally, using new technology or insights to keep users engaged and ‘delighted’. This means that they will stay motivated and passionate about you and your product, and therefore loyal to you.
4. Strategic features – There are also features which need to be done for strategic reasons – such as for data collection, or for users to experiment with, before you can go on to another part of the project.

By prioritising your product features in this way, you will ensure that you are attending to the most important features first, ensuring both customer satisfaction and securing funding to continue the project until the final.

Another option is to pick the low hanging fruit first – the features which are quickest and easiest to do, so that you can then concentrate on the more complex features. This is also a great way to stay motivated and show that you are making progress.

Creating user stories, then analysing and prioritising the data that the user stories have given is vital in the completion of a product project. It means that you can see the product from a user point of view, ensuring that the product is designed and adapted to suit the customer’s needs – which is of course the key to a successful project.

If you have any questions about understanding user stories, prioritising and how to use this in the development of a product, get in touch with Studioworx either via email ([email protected]), telephone +44 (0)1603 274285 or the website (https://www.studioworx.co.uk).