User stories in a nutshell

By Simone Slaviero

How often are you considering user needs during the development lifecycle? And how are you documenting this for discussion, implementation and follow up? Regardless of whether you're new to user stories or they're part of your daily operations, we have gathered our top tips to either help you get started or keep you on track!

What is a user story?

For many, a user story represents some type of requirement that needs to be actioned. This is true - to some extent. However, this definition only covers a small part of a bigger picture. To put it simply, a user story describes a need or 'requirement' from the perspective of, you guessed it, the user. Which is a brilliant place to start, since users should be one of the main reasons driving changes to your website.

User stories should be:

• User-centric – keeping user needs, goals, experience, and behaviours in sharp focus
• Enablers of both high-level user need exploration as well as a more explicit actionable level
• Short, specific, and goal-oriented
• 'Bite’-sized – suitable for agile software development

This way, they can serve as a valuable reminder to always consider the user when creating a solution during the development of a website, intranet or other type of digital product.

However, a user story does not usually focus on the business or technological needs. Elements not usually covered by user stories include the corporate vision, goals, stakeholder needs, budgets, roadmaps, data migration, system upgrades, and application integrations. All these things can be discussed and documented in many different ways or, scarily, sometimes not at all! It all really depends on your chosen project management methodology and tools, as well as the level of detail required. In some cases, you might find it relevant to maintain super detailed specifications for functionalities and system requirements. At other times, light documentation may be enough.

Why write a user story?

When it comes to documenting user needs, we find it super effective to apply the user story method. It works for us and our clients because user stories:

• Are non-technical, and therefore easier to understand
• Encourage collaboration and discussion across multiple roles and teams
• Are a lightweight technique to define user needs & develop fast
• Provides a basis for tracking, forecasting and reporting in agile project management
• Improve estimations & task creation by developers and testers
• Promote structured testing
• And, most importantly, they help us keep the user in focus. 

How do I write a user story?

Perhaps you are already familiar with the user story format shown below:

AS A <type of user…a PERSONA> 
I WANT <some goal…the WHAT?>
SO THAT <some reason…the WHY?>

Before we move forward, it's important to remember that user stories do not describe system or technical needs, solutions, nor do they cover stand alone business/functional, technical or non functional requirements.

To put it into context, think about the following scenario: jobseekers who are looking to either start or continue their career with your company. In this case, the type of user is the jobseeker. Their goal is to find available positions in your company so they can submit an application. We have enough information here to phrase this as a user story, like so:

AS A jobseeker
I WANT to discover available positions 
SO THAT I can apply to begin or continue my career at your company

Let's call this our high level or 'epic' user story, since it still leaves many things unanswered. For example:

• What characteristics or attributes define the jobseeker 'user'? What are their skills, experience, and background?
• What sort of positions is the user after? Do they want a job in a specific location?
• Why do they want to work at our company?

The great thing about user stories is that they are iterative – we can add detail to them to make things less ambiguous, based on research and the knowledge gained about the user and their needs. For example, we could write another user story that is more explicit about the user's jobseeking needs:

AS AN experienced business controller in Munich
I WANT to find a job somewhere in southern Germany that is related to my background 
SO THAT I can develop my skills in a company that I find interesting

User stories alone are not enough

The user story teaches us a lot about the user, particularly when we drill down to a more detailed level, and yet we could still miss out on many more questions or details that would be useful to discuss. It's common practice to break down a high level ('epic') user story into multiple, more concise ones, until there is sufficient coverage to explain all of the user’s separate needs.

From here, we can provide supporting detail to make a story unambiguous by adding acceptance criteria. This will also help make a user story actionable and testable. It's through acceptance criteria that we can expand on user needs and list specific requirements, including any business, design or technical criteria that need to be met to achieve the story.

For the German business controller, some acceptance criteria could be as follows:

• User can filter jobs by country(s)
• User can filter jobs by city(ies)
• User can choose one or multiple locations in search
• User can exclude one or multiple locations in search
• User can search by keyword and filter on relevance

Acceptance criteria can be added in different ways, commonly as bullet points stating what must happen when an action takes place, or as conditions or specific values/thresholds that need to be met. They provide a checklist that, once all items have been accomplished, will allow you (the tester) to confirm that the user story can be successfully fulfilled. You may also find that you need to state acceptance criteria more formally and in more detail through a GIVEN, WHEN, THEN format. Whichever way you choose to document acceptance criteria, each criterion must be independent, measurable, and have a clear pass/fail outcome described. 

User story tips

Do:

• Keep it simple
• Break them down from a higher level
• Add Acceptance Criteria (AC)

Don't:

• Rely solely on the user story
• Write more than one goal per story
• Jump from epic user stories straight to developer tasks

How do user stories fit into the bigger picture?

After reading this, you might decide to continue using user stories or even start using them for the first time. However, you may be wondering how to really fit them in amongst everything else you have to juggle on a project. Depending on your chosen project methodology and tools, you might decide to add user stories to flesh out epics and other features that have stemmed from higher level roadmap themes. Keep in mind that 'epic' might refer to both the size of a user story and a container that groups up features, stories, and tasks in agile project management.

User stories can be mapped to other requirements and tasks using different methodologies along with tools such as Jira and Miro. This can help project teams to get a holistic overview of the needs, interactions, and dependencies between users, business, and systems. 

No matter how you decide to incorporate user stories into your upcoming or current project, know that they will always serve as a reminder to consider things from a user perspective. And that is always a positive in our books!

Learn more about how we can help you with your digital corporate communications, or contact us directly!