User Story Structure

Episode #9 of the course Product management toolkit by Rich Headley

 

Welcome to lesson nine. This lesson is a bit longer because we’re going to talk about user story structure, a topic that is super tactical and quite elementary to the day-to-day in product management. User stories are so often structured in incomplete, inconsistent, or inefficient ways, and this hinders your ability to deliver high-quality products to your customers with adequate speed and minimal cost.

I told you at the beginning of the course that you have to think of yourself as a pain scientist. You’re studying, hypothesizing about, and experimenting with how to solve real people’s painful problems. Well, science doesn’t end there. Remember from high school chemistry how the basic building blocks of matter and life are things like atoms, molecules, and organisms? If you think about product requirements and how they should be organized, it’s a similar atomic structure.

A whole product can be considered an organism. It’s a complex being composed of all the things that have been put together to make it do things in the world. Now, an organism is made up of multiple molecules. Molecules are much smaller and simpler, so we can think of a product’s individual features as molecules. Keep in mind, some big features might be super complicated and perhaps be large enough to be considered organisms themselves, with parts of the features being at the smaller molecule level, but it doesn’t matter. The point is that we’re getting down to the essential building blocks of product requirements. When we build a new feature, we often write and track those product requirements in what’s called an Epic. An Epic has an intended end-to-end business purpose, and it’s composed of multiple user stories.

So the building block of product requirements that is the most elemental (pun intended) is a user story. We can think of user stories as atoms. A single user story is uniquely identifiable, but it should always have certain elements within it that make it a whole story. Just like an atom wouldn’t be an atom without the particles like protons, neutrons, and electrons.

The point I’ve been leading up to is that sometimes product managers try to make an atom without including all of the components: they leave out a proton, neutron, electron, or maybe they put in too many, and when they try to mash that weird atom into a molecule with other atoms, something goes wrong. The feature molecule is a bit off, perhaps because the team may have misunderstood the product manager’s intent, they were trying to do too much at once, or because the product manager may not have thought clearly enough about exactly which type of atom was needed to make the molecule useful to the organism.

So what are those things that so many PMs so often do wrong when making their user stories? It usually comes down to five things: formatting, scope, persona focus, value, and situation.

By formatting, I mean that PMs don’t keep a consistent, predictable format that team members can rely on to do their jobs. Perhaps they don’t have a good title that indicates what the story is about. Maybe there isn’t a quick, succinct user story sentence at the beginning that covers all the bases. More on that later. Often, PMs don’t include success criteria in their user stories, meaning they aren’t making it clear to the team which things must happen, or which things must be tested, to meet the definition of done. Or, maybe there isn’t clarity on the designs included in the story. Some teams have a working agreement where they expect pixel-perfect designs in the stories, while other teams are more flexible and forgiving if some aspects of the designs are a bit rough because there is the trust placed on the team to build the actual product following the specifications of a product design system where front end components are already available in a library and don’t need to be built directly off of the mockup in the user story.

The next thing PMs often get wrong is the scope of their stories. What I mean here is that often PMs try to do too much in one story. They list out several scenarios, use cases, and edge cases that need to be covered. Now it’s great that here the PM is trying to make sure nothing is left out, but it also makes it difficult for the team to ship product quickly and know what is truly the most important. A way to know when your story may be too big is if the size the team gives it during backlog grooming is larger than the average. Think about how to split the story into two independently testable and deliverable pieces of functionality.

The next common user story pitfall is where a PM lacks clarity on which persona the story is being written for. They start their story with “as a user, I want to…” rather than being more specific about which user they’re talking about. This is too easy to fix, and you just have to think about who’s getting the value here. It’s especially important where you’ve got end-users and administrators using the same software application, because those personas have different goals, permissions, and even familiarity in the system, so they’d expect to see and do different things.

Another area where user stories commonly fall short is that the value isn’t clear. Going back to the typical agile user story format, the PM might say something like “As an online store customer, I want to reset my password.” OK, sounds pretty straightforward, but what is the actual reason you need to make this possible? It’s important to include the why at the end. A more complete user story statement would be “As an online store customer, I want to reset my password so that I can access my account without having to contact support.” Now, we’re getting clear on the value you’re trying to unlock. And because we are trying to provide convenience for end-users, we can think about what kinds of friendly language we can use during the password reset process to empathize with the customer’s frustration and increase their satisfaction.

Beyond identifying the who and the why in a story, it’s also helpful to identify the situation the persona is in when their problem needs a functional solution. Building on the typical agile user story format, we’d add a “while” statement after the persona. With the password reset example, it’d be something like “As an online store customer, while my account is locked, I want to reset my password so that I can access my account without having to contact customer support.” Now, we’re being more specific about a situation where not only does the user want to reset their password, but they’re also trying to do it while their account is locked. Depending on the type of application, you may want to consider whether a locked account should be treated any differently for security purposes. Another common reason for using a “while” statement is to just make it clear which page the user is on, and what state it’s in when performing their action. Otherwise, you’re leaving your team guessing a bit.

Well, there you have it. Five pro tips on how the best product managers write great user stories. And the best part is that these things don’t require any superpowers—just that you consistently apply them.

In our next and final lesson, we’ll quickly review highlights about all of the tools covered in this course. It will be perhaps the most important lesson because it’ll help to reinforce your learning and retention.

 

Recommended reading

10 Tips for Writing Good User Stories

 

Share with friends