User Stories Aren’t As Simple As They Seem

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

In April, I wrote User Stories Are Better Than PRDs. To date, it’s been one of my most popular posts. It covers the basic format of user stories:

As a user role, I’m able to do some functionality, for some explicit benefit.

It looks at each component and concludes with why I think well-written user stories are better than PRDs. I recommend starting there if you haven’t read it.

Today, I’m going to continue the conversation. User stories are a product of the extreme programming philosophy and have gained in popularity with Agile development. The extreme folks often use the INVEST acronym to represent the six attributes of good user stories:

• Independent
• Negotiable
• Valuable to the user or customer
• Estimatable
• Small
• Testable

Let’s look at each in turn.

Independent: Each user story should be independent of any other user story. This seems obvious but can be really hard to do in practice. The classic example for this is suppose we had the following requirements:

• As a purchaser, I should be able to pay with my American Express, so that I can earn AmEx points on my purchase.
• As a purchaser, I should be able to pay with my Discover card, so that I can get cash back.
• As a purchaser, I should be able to pay with my Visa, so I can increase my chance of winning SuperBowl tickets.

Each of these stories seem fine on their own.They each have a unique function and benefit. But suppose our site doesn’t handle credit card processing at all. There is probably some upfront work to be done to process any credit card. So how would the team estimate each story? The story that was implemented first would incur all the overhead of credit card processing while the others would be much easier. This can be resolved, by simply adding a story:

• As a purchaser, I can pay with at least one type of credit card, so that I’m able to quickly checkout.

This story can be estimated separately and the other stories can represent the specific work needed to represent the specific type of card.

But this doesn’t really resolve the dependency. This new story must be implemented before any of the other stories can be implemented. It turns out in practice, writing independent user stories is impossibly hard. Development (especially Agile development) is incremental and iterative. That means functionality is going to build on prior functionality, meaning dependencies are going to exist.

Independent here really means remove any unnecessary dependencies. If we didn’t add the separate credit card processing story we’d have to arbitrarily pick one of the credit cards to implement first. It would look like that card was significantly more work than the other cards. By separating out the work, we remove that particular dependency and are better able to represent the work required to implement different card types. This allows us to better prioritize the stories.

I would say more often than not dependencies are more insidious than this example.  For people new to story writing, this can be one of the hardest things to learn. It takes practice. One of the ways you can learn to avoid unnecessary dependencies is to ask, if this story was the only story to be implemented, does it add value. If the answer is no, you want to examine why and do your best to remove any unnecessary dependencies.

Negotiable – Product managers who are used to writing PRDs and working in a waterfall environment often view requirements as a contract. This is not the case with user stories. One of the benefits of using user stories is that they facilitate conversation. Throughout development, there should be an ongoing dialog between engineering and the rest of the business.

Let’s continue with the credit card scenario. Suppose we had a PRD that required the service support American Express, Visa, and Discover. This seemed reasonable at the time that the requirements were written. But as the engineers start implementing, suppose they uncover that to support Discover they have to implement a set of security requirements that are completely different from the other cards, adding two weeks of development for that one option. This is exactly the type of thing that makes user stories negotiable.

This information may not have been available at the time the requirements were written. But now the engineers can discuss with the product owner whether or not this functionality is worth the development time, given this new information.

A good rule of thumb is that user stories should act as conversation starters. They aren’t contracts. An engineer should feel free to question a requirement if new information arises. Similarly, the product team should be able to revise a story if new information from the business arises.

Valuable to the user or customer – This one sounds obvious, but I see a lot of stories that don’t meet this requirement. Before you snicker in derision, ask yourself how often you see stories like this:

• As a new registrant, I am able to verify my email address.

Note that this story has no benefit. That’s because I can’t think of a single benefit to the user for verifying their email. Yes, there are some exceptions. But the vast majority of the time, verifying an email address benefits the site owner not the end-user. So what do you do?

I’d argue you verify the email automatically after the user engages with any of your emails. In other words, I’d change the requirement to be the side effect of something that actually benefits the user.

Also keep in mind, user stories shouldn’t prescribe UI elements. Leave that up to your designer. Instead, focus on the desired outcome for the user. Nor should they include technical details unless again they are written from the perspective of your customer or user.

Estimatable – The team should be able to estimate each story.There are three common reasons why a story may not be able to be estimated.

The team may be missing information. Suppose we are working on an event site and we are estimating the following story:

• As an event host, I am able to select the venue from a common list, so that I don’t have to enter the address by hand.

Without knowing where the venue list is going to come from, in what format the data will be, how reliable the data will be, what type of venue coverage it will include, it will be hard for the team to estimate this story.

In this case, the solution is to track down the missing information before having the team estimate the story. Remember, user stories are conversation starters. It’s perfectly acceptable for the team to say we need more information.

Or sometimes the missing knowledge is of a different nature. Often times a team can’t estimate a story because they don’t know yet how to solve it technically. Suppose we have the following story:

• As a potential event attendee, I’m able to browse events based on which events my friends are attending, so that I can quickly find events that I’m likely to attend.

Even if the team knows where the friend data and friend attendance data is going to come from, they might not have a good solution for storing this data or processing this data in a way that allows for easy browsing.

You might be tempted to break off a piece of this and add:

• As a developer, I’m able to store an event attendee’s friends and friends’ attendance data, so that I’m later able to build browse functionality.

I see this a lot. But this is a terrible idea. First, it violates the last attribute – it’s not valuable to the user or customer. Neither cares that you have to store the data to get the desired functionality. Second, this doesn’t really solve the estimating issue. If there isn’t a known solution, then it’s still going to be impossible to estimate.

You are better off punting on this user story and adding the following task to the current sprint:

• Research and prototype potential storage solutions for friends and friends attendance data storage.

Not everything in your sprint needs to be in story format. And sometimes you need to do research before a story can be estimated. A key recommendation here though is to time box this task. Add something like, spend no more than 3 days on this task, as this allows the team to re-evaluate based on what they’ve learned before committing more time.

And finally, some stories are just too big to be estimated. These stories are typically called epic stories and should be split up into smaller stories so that each component can be estimated. But again, when doing so, make sure that each story creates value on its own.

Small – We’ve already covered most of this one. Epic stories that can be broken up into a set of smaller stories should be. Stories that are too big because there are too many unknowns should be punted until the necessary information is discovered, even if it means there needs to be an engineering task to uncover the information.

In theory, stories can be too small as well. But I rarely see this.

Testable – And finally, each user story should be testable. This is another one that I often see overlooked. First, the story itself should be written so that it can be testable. For example, this is not testable:

• As an event attendee, I don’t have to wait for the page to load, so that I can get on with my business.

But this is:

• As an event invitee, I don’t have to wait more than 1 second for the event page to load, so that I can quickly go about my business.

This is not testable:

• As an event invitee, it should be clear how to RSVP, so that I am more likely to do so.

This is:

• As an event invitee, I should spot the RSVP section within 30 seconds of scanning the page, so that I am more likely to RVSP..

In addition to the stories being written in a way such that they are testable, they also should have acceptance criteria added to them before the team starts implementing. I see a lot of teams add acceptance criteria as they build. But this leads to testing what was built versus what was intended to be built. Read that again, it’s a subtle point.

If you add acceptance criteria before you start building, the team is more likely to test the intended functionality rather than the functionality that was actually built.

Just like the user story itself, acceptance criteria should be written from the perspective of the user or the customer. And someone who represents the user or customer (if not the user or customer themselves) should test that the story passes the criteria.

And now for a final caveat. You can waste a lot of time and effort following these rules exactly. If you are new to story writing, I’d recommend trying to stick to these as much as possible. But as you gain experience, you’ll realize there are times when these rules just don’t make sense. Use your best judgement. The goal is to write stories that facilitate a conversation between the business and engineering, that allow the team to estimate the work so that they can be prioritized, and such that the right product gets built. When you see problems crop up in any of these areas, it’s a pretty clear sign that you might want to revisit the quality of your user stories. Otherwise, carry on, there’s plenty of other work to do.

Want to learn more? I recommend User Stories Applied by Mike Cohn.

Do you have your own tips for how to write good user stories? Or have you seen other problems that you don’t see addressed here? Please share in the comments.