How to Write User Stories to Support App Development

The end goal of a software project is never just about delivering a piece of software. Most of all, it’s about providing the desired benefit to the end user, growing the product’s user base and reducing churn through excellent UX. Easier said than done, right? Well, if you get the product backlog and user stories right, you give yourself a very good chance of achieving this goal. Here’s what you need to know about these important elements.

What are user stories?

In a nutshell, a user story is a description of the app’s functionality. It should be understandable to everyone in the team, from the Product Owner, through to the developers, designers and testers.

The common and most used template for creating user story is: As a < type of user >, I want < some goal > so that < some reason >.

Example:

As a customer, I want to have a sales dashboard in my account, so that I can easily track my income.

I.N.V.E.S.T. - the attributes of a great user story

A common principle for working on user stories is INVEST - an acronym devised in 2003 by Bill Wake on XP user forum. Here is what each element of the acronym stands for.

I for independent

As much as possible, we should ensure that our stories are independent and that they don’t overlap with one another. In principle, you should be able to schedule and implement them in any order.

N for negotiable… and Negotiated

Your user story should also be negotiable and should be created together by the product owner and developers during the development process. Therefore, you shouldn’t view each story as a contract or promise of a certain feature being delivered. Over time each of these tasks will acquire notes and may well evolve.

V for valuable

Here, we’re not talking about the value to the end user, but to the product owner. This should enable them to handle prioritisation and scheduling.

Note on splitting stories: Developers have a tendency to work on only one layer of a story at a time (such as a logic layer or a presentation layer), but their aim should be to give you, the Product Owner the essence of a whole cake, which can best be done by slicing vertically through the layers. Think about it - out of context, a database holds little value, but if you understand how it sits in the larger product, you can begin to make decisions about it.

E for estimable

You should aim for each of your stories to be easily estimated. Estimates don’t need to be exact, but they should be enough to help the product owner to rank and schedule where the story should go in the process. Remember that estimation goes hand in hand with negotiation, and estimations will definitely vary depending on the team’s experience.

S for small

Larger stories are difficult to estimate and implement. This is why the most effective stories tend to be small. On the whole, they shouldn’t be longer than a few weeks of work for a person or team.

Initial story descriptions can be small too - remember that they can later be elaborated through conversations with the Product Owner.

T for testable

Teams have reported that by requiring customer tests before implementing a story, the team is more productive. That’s why it’s useful to think about how testable your story is. Remember that if your Product Owner

If a customer doesn’t know how to test something, your story may not be clear or valuable enough to them.

Slicing stories in the right way

There are many techniques and approaches to splitting user stories to decompose them to their smallest possible size (that still would deliver value). As noted above, the first rule of decomposing is to slice through the stories vertically.

Switching the user story pattern

One simple tool to control for value delivery is switching the order of the user story pattern. Instead of saying “As a user, I want to view my orders, so that I can check their status”, you can reorder the story and say “so that I can check the status of my orders, as a user I want to …” and then think about the possible options - viewing on the website, viewing in the mobile app, automatic push notifications on mobile about status change, automatic alerts about order status change displayed on the website, email or text notifications, and so on.

The Product Owner can then decide which of the options make sense based on users’ needs, split into single user stories and decide in which order they should be implemented. That way, you also end up with smaller user stories.

Remember also that anyone in the team can and should challenge the PO to think in this way. During the project, it’s a very good technique for refinements, as it starts with the actual business need and the “why” of delivering the software.

Implementing workflow steps

Some user stories may actually describe a workflow which includes several steps. In this case, the discussion during refinement focuses on the workflow steps and constraints, and the original story can be split into several. Such cases require longer discussions.

Removing vagueness

It helps to be as specific as possible. For instance, rather than writing about ‘users’ in general, you might want to say ‘returning users’ or ‘newly registered users’ - as each of these groups might have an entirely different journey. Make sure that all team members are aware of the definitions of important terms - e.g. what does ‘current’ mean? Does it refer to data from today or the whole of this week?

Here, the perspectives of developers and testers are invaluable, because they typically think of these very concrete questions and can help in slicing and splitting the stories, and concentrating first on the simplest or most valuable ones.

Splitting conjunctions

Another quick approach is to check for conjunctions. This can also cover splitting according to the platform on which the solution should work, though the same effect can be achieved by another technique: when the PO is asked about acceptance criteria, this can also lead to splitting the original story to simpler chunks.

Remember to keep talking

You need to remember that as Product Owner you’re in touch with stakeholders and have a good understanding of the business needs, but you may be lacking technical expertise. That’s why the perspective and input of the development team members in interaction with the Project Manager is so important when managing the backlog. Clarify anything that you don’t understand and always aim for simplicity.

Looking for an expert team to bring your digital product to life?

Get in touch with me for a free consultation on hello@10Clouds.com. Our friendly team will get back to you within one working day!