How to Write User Stories

User stories are a way of capturing requirements that are commonly used on agile software development teams.

The cornerstone of a user story is a single statement in the following syntax:

“As a [user], I can [do something] so that [perceived benefit].”

Discover the benefits of user stories and how they fit into the BA workflow by watching the video below.

Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about user stories and how to write user stories and be really effective with this technique as an agile business analyst.

User stories are a way of capturing requirements that is commonly used on an agile software development team or a team using the agile methodology of some sort.

Benefits of User Stories

There are some really key benefits to managing requirements with user stories.

First of all, when you’re using user stories to manage your requirements, you’re often organizing all of those stories into the product backlog. That allows you to rank prioritize the requirements, which is a very agile focused technique, as opposed to like a big document where everything is “priority one.” That rank priority makes it incredibly clear which requirements are the most important and most valuable to the business. You, as the business analyst are focusing on the most important requirements and the development team is also focusing on the most important requirements.

And now the other piece that I really love about user stories is the very syntax of how they’re written, which we’re going to go through in just a minute here, links each functional requirement to the anticipated business benefit, and that makes it much more difficult to just sort of add in or sneak in requirements in a big document or even in a use case. I love use cases, and we’re going to talk about how to incorporate those into your user story development process a little bit at the end.

What I have found when I only write use cases is they can get a bit bloated with extra steps and alternate flows and all kinds of exceptions, and all of a sudden something that seemed really simple becomes really complex and that becomes very obvious when you are breaking down the requirements from a use case into user stories because then you have to prioritize each of those independently.

And then the final thing I really love about user stories is that they create this powerful link between your requirements work and your development work which helps us, again, guard against unnecessary scope creep, or projects that really become more intensive without actually creating more value. That’s a great position to be in as a business analyst, making sure you’re paying attention to value.

User Stories Defined

So what is a user story? The cornerstone of a user story is a single statement in the following syntax. As a user, I can do something so that whatever that perceived benefit is of that feature. And then you include whatever accompanying details or supplemental materials you need to make the user story clear and implementable.

Often these are detailed in acceptance criteria or the conditions the software must satisfy to be accepted by a user, a customer or a stakeholder.

An Example User Story

Let’s go ahead and look at an actual example, which I think will make this much clearer.

This is an example that we include with our use cases and wireframes module of The Business Analyst Blueprint training program®.

As you can see up here, the title for this is The Username Doesn’t Exist. This is a component of a bigger use case that would be logging into the system. That use case has multiple different features and exceptions and alternates. This is just one little piece of that. What happens if the user tries to log in and that username does not exist in the system? Up here we have a, as a user. I can be notified that the username I provided does not exist so that I can provide a different username or try to log in again.

Here we have our different acceptance criteria. They’re written in this given when/then format. So given this happens, then this happens. Given this happens, then this happens.

Now what we’ve also included here is a wireframe. And what I have found as a business analyst, it’s often really helpful to have not just the acceptance criteria detailed out in words, but to have some sort of supporting documentation. In this case, the wireframe made the most sense. Other times it might be a workflow diagram. It might be the use case that this user story is a part of. It might be a data model, if it’s data intensive. It could be a data dictionary or a glossary of terms, or an ERD, like a piece of the ERD. Those are all examples of what you could include as supporting documentation. In this case, we have a wireframe.

So that’s an important piece to keep in mind. There’s some specificity to user stories, like guidelines, and how to create them. But I think there’s also a lot of judgment as a business analyst of what actually is going to communicate these requirements in the most effective way to my software development community.

Wireframes are super common. Here’s a video explaining how to create a wireframe if you want more detail on this business analysis technique:

How User Stories Fit into the Business Analysis Workflow

I think another thing that we really need to keep our mind wrapped around is how these user stories fit into our workflow as business analyst.

One area that often gets overlooked in agile circles, even still today, is how the development of the user stories fits into a business analyst process framework.

If you aren’t familiar with what a business analysis process framework can look like, here’s a video tutorial on that:

Agile is a Software Development Process, Not a Business Analysis Process.

Agile is a software development process. It is not a business analysis process.

Most agile methodologies, whether they explicitly do this or not, there’s some sort of assumption built in that the details of what goes into a user story are fairly well known or easy to figure out, and just a matter of the business analyst sitting down with a user and really figuring that out and having one quick conversation with them.

The reality is that often as a business analyst:

You need to be collaborating with multiple stakeholder groups to rank and prioritize and estimate those user stories.
You might need to gather information from multiple different stakeholders groups to build out that acceptance criteria or to gain alignment on what the software actually needs to do.
You might need to dig in and figure out what the business process is before you even start defining what those software requirements are.

There could be a lot of background kind of upfront work that even though we want to be more agile, we also want to be thinking things through.

As a business analyst, when I’m on an agile team, I’ve found it a good practice to work ahead at least by one or two sprints, and that’s if things are relatively simple.

If you’re dealing with something much more complex where there’s a big business process focus, you might need to work even further ahead than that kind of doing some of that business process work before you get into the sprint part of the development process.

What that means is that I’m always prioritizing the product backlog that will be developed in the next month or two. That gives me time to refine those requirements, to get all the necessary stakeholders on the same page about those requirements, and to detail out those acceptance criteria so when we go into sprint planning, I’m ready with the good draft of what the requirements are for this user story, and then we can have dialogue with the technical team. I can go back and clarify things if I need to or add to them or supplement them.

But I’m not doing the heavy lifting of getting all the stakeholders on the same page while the developers are trying to build that feature. I’ve done that before under the pressure of agile. What happened is we built one thing and had to change it and build it again and nobody was happy, especially me, especially the developers as well. .

When Focused on User Stories, It’s Easy to Lose Track of the Big Picture

The other thing I want to say is that when we are focused on these little user stories, especially like that example of “the username doesn’t exist,” it’s a little tiny piece of functionality. It is really easy to lose track of the big picture. And when you lose track of the big picture, it’s common to miss requirements because you’re focused on this one little piece. As a business analyst, you need other techniques to maintain a view of this big picture.

What we teach at business at Bridging the Gap is use cases because we find that use case thinking and the semantics and the logic of a use case helps business analysts uncover otherwise missed requirements. And if you are a great agile business analyst, you’re like, “Laura, I write user stories all the time. I don’t ever write use cases,” that is totally possible. I’ve done that too, but it’s because I had that use case thinking background in my head and I was thinking through the use cases, even though I wasn’t writing the use cases and I was using that use case thinking to hold together and think through how all these user stories fit together.

And so it might be that use cases or use case thinking has become so intuitive to you by now that you don’t actually have to write the use cases if you’re new and struggling with how to make sense of this big glob of user stories that you might have on your plate. You might want to actually put them together into a use case or a business process model, or a process map, or a workflow diagram to help you think through that bigger picture view before you dive into each individual story.

Download our Use Case Template

If you’d like to go further on the use cases specifically, I do have a free template for you that you can use to walk through with some guiding text. It’s absolutely free. You can just use that link below.

And again, that technique is going to help you avoid missed requirements and think through the big picture of how your user stories fit together.

Again, user stories are an incredibly important technique. We need to know them as business analysts, especially if we’re working on agile teams. Mastering use case thinking is going to make you a stronger business analyst who can weave those user stories together in a meaningful way to ensure that the team delivers a solution that’s truly valuable to the business.

Again, my use case template is available through that link below. We’d love to help you take the next step with this skill in your career.

I’m Laura Brandenburg with Bridging the Gap and we build our profession one business analyst at a time. Success starts with you. Thanks for being here.