Don't forget to INVEST in your user stories

When you work in digital and you need to make a change to a system, a program or web application, it should always take the form of a user story.

Why is that? Without users there is obviously no need for an application. You always need to describe what needs to be done from the perspective of the end-user, of the person using the tool.

User stories can reduce the overhead in documentation and accelerate the overall software development process.

How do you write good user stories and how do you make the most of them?

Let's get to it.

The user story format

I think they really apply anywhere when you need to describe a specific feature. The user stories are there to help everyone in your team to plan and visualise upfront what should happen. It gives all the necessary context and information to the developers, the testers, and everyone else who will build, launch and use that feature.

When it comes to user stories, you've probably heard about the specific format of:

"As a <user>, I want to <perform an action>,
so that I can <achieve a specific goal>."

The user

The first part of that sentence is always about the WHO, the user. You can have multiple personas interacting with your web application. You need to think about how each one is going to use that functionality. There might be multiple user stories based on who the user is. It might be a first-time user, a returning customer or the Admin editor. From their point of view, they're going to use the features differently.

The action

The second part describes the WHAT. What is the actual action that the user is doing? What's the main step in that process? It could be submitting a form, triggering an API call or reaching a key milestone somewhere in the user journey.

The value

The third and last part documents the WHY. What is the reasoning behind that action? What's the end goal? It can link to a business KPI or the actual underlying value. It's really important because it gives the team more context about the true objectives of the features and why it should be built in the first place.

Now that you have a well-formed user story, explained in a single sentence, you need to enrich that with acceptance criteria.

The acceptance criteria

Those acceptance criteria complement the narrative and describe more about the conditions and what should be achieved, so when someone tests what's been built, they can confirm that it's done with all the different parameters, permutations and validation rules for example. They can make sure it's working.

This is where you also need to enrich the user story with the relevant parts of your UX research, the prototypes, the visual design storyboards, every piece of information that applies to that feature to give all the information to the development team in one place.

What about EPICS?

It can be a tricky process: the first time you're going to do it in the first round, your stories might be very large and not very detailed, but this is fine. You always start with EPICS that describe the whole module, but they're still very helpful to capture the rough scope. You can then iterate over those and break down the module into smaller functionalities, with more granular, feasible and testable user stories.

It's only at that stage, when everything is described is small chunks with a lot of details, that the development team can come in and start estimating each feature, and actually start building a timeline of the different releases.

The INVEST framework

To summarise what makes good user stories, I'll share the INVEST framework. It was released by Bill Wake back in 2003, but it's still very applicable today.

In "INVEST",

• The "I" stands for independent. This is where the user stories should not be linked between each other. Each should be done in isolation.
• The "N" is negotiable because as we described, it's a team effort to discuss, negotiate and agree on how things are going to be built.
• The "V" is for valuable, to clearly link each user story to how it will help the end-user. And what's the value we're delivering.
• The "E" stands for estimable. Not a large epic that's too vague, but a smaller user story.
• The "S" stands for small. It ideally needs to be a feature that can be done in a few days.
• The T is for testable, that's where the good acceptance criteria come in.

The final piece of advice that I would give you today is that during the whole process, it's really important to have a strong product owner, who has a good understanding of the users, the markets, the business, and can make everyone collaborate well.

So that's it for today. If you're struggling to communicate your development roadmap with user stories, or if you need help to upgrade your current processes, just get in touch. Don't forget to subscribe to my YouTube channel and follow me on Twitter to keep learning with me and grow your career in digital.

Until next time, stay safe and see you soon.