“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness …” so starts the classic “A Tale of Two Cities” story by Charles Dickens. I get excited every time I read that opening because I know it is the beginning of a great journey the author takes me on. Well I want to get you excited about how to write user stories that also are about the journey. A journey that leads to developing the right thing for your users.

It’s About the Conversation

First, I want to make sure I get this point across. The user story is about the conversation that ideally happens between the people that want the product and those that are going to build the product. It is about the conversation and not about how much detail we can put into a user story so that someone else can just read it, try to interpret it and build it. What is the intended purpose of the User Story? You guessed it, the conversation!

I love the graphical depiction below in Jeff Patton’s book, User Story Mapping. It illustrates the value of the user story and how we reach a shared understanding through continuous conversation.

For some context on the graphics below, the yellow figure could be a user, blue figure a product owner or business analysts, and the red figure a developer or tester. In the first scenario we have written everything down and passed it off to the next group to work on it with minimal conversation assuming that it was documented with perfect clarity.

In this next step, the user story is acting as a placeholder for a conversation. When the conversation does occur the misunderstanding is realized.

We then continue the conversation until we have reached a shared understanding of the need.

And, voila, a shared understanding. Make sure the shared understanding is reflected in the user story.

When user stories first came into being they were typically written on 3″ x 5″ index cards and therefore constrained to what could fit on it. This forced conciseness and ensured a conversation to figure out what is needed. Even with a digital management tool like Jira, Version One, Trello, etc… with no constraints on how much can be added, make sure the must have elements (detailed below) of a user story are able to still be printed onto an index card and fit without having to use 2 pt font. 😀

Must Have Elements of User Story

I have found that the must have elements of a user story are: Who is this for, What do they want, Why do they want it, and Acceptance Criteria (aka conditions of satisfaction). How these are expressed in the story isn’t important, just that they are. A commonly used format is, “As a <user/who>, I want <goal/what>, so that <benefit/why>.”

Who (User)

This should describe a fairly detailed user. It is not sufficient to just say “user.” Strive towards something like “broke college student on a mobile device user.” When we express the who with more detail we are able to better empathize with that particular user, determine the best solution and uncover implicit needs.

What (Goal)

The goal or action the user intends to take.

Why (Benefit)

Expressing the benefit to the user is by far the most important in my experience. Some of the most creative and inexpensive solutions come from the developers and users understanding why they are building something.

Acceptance Criteria

Describe the list of criteria that enables knowing when the story is completed. These should be indicative statements (True/False), in present tense, objective, unambiguous, and have examples if possible.

User Story Example

Let’s put these must have elements into a user story example. Imagine the first part being on the front of the index card and the Acceptance Criteria on the back.

As a competitive type-A homeowner,
I want my lawn maintained to perfection,
so that I can win the annual best lawn award

Acceptance Criteria:

• Blades of grass are 2 inches tall from the top of the soil
• Grass is RGB color value 0, 153, 0
• 1 inch edging gap between grass and concrete
• No weeds

What about other details?

Some may ask, what do I do with the specfication document, wire frames, test data, use cases, test scenarios, etc … Well I don’t have any issue with any of these being attached to the story as long as they add value to the conversation and don’t lull us into a sense of feeling we don’t need to have a conversation.

Well that was a bit longer than I was thinking. 😳

If you take nothing else away from this, make sure the stories that you write are a placeholder for a conversation to happen between those that have the need with those that are going to build it. Do your best to bring these two groups as close together as possible. And make sure the must have elements can still fit on an index card. Happy writing and conversing!! Cheers to building the right thing!!

Please don’t hesitate to comment below about your experience writing good stories.