The Complete Story Behind Agile User Stories

You encounter these all the time during your sprint reviews, sprint retrospectives and sprint planning meetings: User Stories.

We’re sure you know what they are, but do you really know what an agile User Story does? Do you know how to write a User Story? Should you be focusing on multiple User Stories in parallel?

Sit down, we need to talk. We’re here to give you the lowdown on exactly what a User Story is: the whole truth, and nothing but the truth.

What is a User Story: An Explanation

Most devs we speak to will tell you something along these lines:

“A Scrum User Story is a description or a template of what needs to be done.”

Actually, a User Story goes much deeper than that: it's an explanation of a feature, told from the perspective of the end user, giving further detail on how that end user will gain value from it.

That means they’re so much more than just a feature requirement. And that’s not all.

There’s tons to learn about what’s a User Story.

Agile User Story Examples

The best advice we can give you when writing User Stories is to keep things short, simple and to the point. If possible, keep your User Stories to one sentence only, focusing on the ‘who’, the ‘what’ and the ‘why’. See the section below for User Story templates!

How to Write User Stories: A Scrum User Story Template

As we mentioned above, your User Stories should be kept as short and sweet as possible. Here’s a solid User Story template you can adapt to your needs:

“As a [end user persona goes here], I [want to do/have this thing], so that [I can get this end result].”

Here are some of the questions you should ask yourself when writing the User Story:

• Who is this feature being built for? Go deeper than just a job title: think about who these people might be in their essence, their ages, their needs, their pain points and more
• What do these end users need and want: what would make their lives easier if you develop this feature? How will it impact their day if all goes according to plan?
• How will developing this feature for your end user fit the bigger picture? What’s the general benefit - to the immediate one - that you're trying to achieve or provide?

User Story Mapping

Your agile User Stories are only as good as their story mapping.

This means seeing your User Story through from beginning to end, making sure each section makes sense, for example:

• What is the user value focus?
• What work needs to be done on this User Story?
• Are the requirements fitting and achievable?
• Is there value in this User Story? What is it, and how does it manifest?
• Does this User Story expose any risks and/or dependencies?
• Has the team reached a consensus on everything about this User Story?

User Story Format

The User Story format fits into every type of agile point framework, from kanban to Scrum. They also serve as the foundation for more long-term, bigger-picture agile frameworks, such as epics, initiatives and so on.

For these large-scale projects to make sense (or for anything to get done on your sprint!), your User Story should contain the following:

• What the definition of ‘done’ is (see ‘User Story Acceptance Criteria’ below)
• Any tasks or subtasks
• User personas
• The logical steps to tackling the User Story
  

If you want to take it a step further, adding an estimation of time to complete the User Story is also admissible (but not a must). Furthermore, it might be in your interest to work on multiple User Stories at once. The answer for this should be up to the team - if they have the resources to effectively take on multiple User Stories then it can be done otherwise, it can prove to be a waste of time; and you're better off focusing solely on one User Story.

Use Case vs. User Story

The issue of use case vs user story has been around since agile teams were born. Which is better, and what’s the difference anyway?

While both User Stories and use cases are focused on users and outcomes, they tend to serve very different purposes.

User Stories are more about the end user’s result, while Use Cases are more about how the system will serve the end user. One is focused on the person, the other on the software.

User Story Acceptance Criteria

Acceptance criteria are the predefined requirements for declaring a User Story done and completed.

Product managers or owners might be responsible for deciding what counts as ‘done’ and finished with a User Story, and could be something along these lines:

• Conditions that would be accepted by the end user.
• Standards or requirements of the larger project at hand (such as the agile sprint)
  

Epic Feature User Story

Since epics are pretty tough to tackle without breaking down, the epic at hand needs to be defined down to feature-focused agile User Stories.

These User Stories are organized and grouped by requested features, while retaining everything about the end user.

GoRetro: Get Your User Stories Perfect from Start to Finish

GoRetro is the forever-free tool that helps you handle your sprint retrospectives. Say goodbye to half-baked User Stories, stories that don’t fit the overall goals of the sprint or aren’t fully focused on the user; GoRetro is here to ensure your next sprint is the best sprint ever!