A deep-dive into user stories

If you find yourself in the midst of an agile software development project, you’ll likely hear the word user story often. Our goal with this post is to clarify what they are and why they are important and share some of our thoughts as to how we can help projects run more smoothly by mastering the art of user stories.

But first, What is a user story?

One of the common definitions of a user story is: In software development and product management, a user story is an informal, natural language description of features of a software system. The concept of user stories originated in the late 1990s, but it’s in 2001 that Ron Jeffries (one of the three founders of Extreme Programming software development methodology) proposes a “Three Cs” for user story creation. These are still relevant today when writing user stories.

• Card (i.e. post it note, Trello card, Jira card, etc.) as the tangible physical token to hold the concepts. Usually these cards are 1-3 sentences long. They summarize the detailed requirements. It’s purpose is to plan better. The card is assigned to the programming team to implement, and returned to the customer when the story is completed.
• Conversation - a verbal and documented conversation between stakeholders (customers, users, development team, testers, etc.). The goal is shared understanding.
• Confirmation - ensures that the objectives of the conversation have been reached.

What format should a user story be?

One way that you can format user stories is with the Connextra user story format. It’s a template you can choose to follow to get you started. It needs to answer the following: Who / What / Why?

For example: As a role I want feature that benefit. This is an effective way to answer those questions.

What are characteristics of a good user story?

Bill Wake (consultant in software development) came up with INVEST in 2003.

• Independent - Every user story you write should be independent of each other. If you think one user story is dependent on the other, you’ve broken down the story too fine. Similarly, if your user story is too broad, it’s most likely an epic. Simply put, a user story by itself should be a working, usable feature your users can use and gain value from.
• Negotiable - A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.
• Valuable - Every user story you prioritize and work on should provide your customers with value and solve their problem.
• Estimable - We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate.
• Small - Stories typically represent at most a few person-weeks/days (depending on the team) worth of work. Above this size, it is too hard to know what’s in the story’s scope. Saying, “it would take me more than a month” often implicitly adds, “as I don’t understand what/all it would entail.” Smaller stories tend to get more accurate estimates.
• Testable - Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met. If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them

What if user stories are not applicable?

Say you’re working on an app/site/software that doesn’t have any user roles. We just have users. What value does a user story bring? We already know who. We recommend trying job stories.

Turns out all user stories can be rewritten as job stories and vice versa.

• User Story: As an estimator, I want to see the item we’re estimating, so that I know what I’m giving an estimate for.
• Job story: When I find an item I want to set an estimate for, I want to be able to see it, so that I can confirm that the item I’m estimating is actually the correct one.

Ok, let’s recap.

User stories are short, simple descriptions of how a feature will be used. They are written in an informal, natural language, from a user’s perspective. It reflects their need and the goal they intend to achieve by using your feature.

It is a small piece of work worth a certain value to the end user that can be built by the development team during the sprint. It describes what a user wants, who the user is, and why they want it. (it does not have to follow the Connextra format! - As a role I want feature so that benefit)

Remember the three C’s - Card, Conversation, Confirmation

A story is not a contract. A story is an invitation to a conversation. The story captures the essence of what is desired.

A story should follow INVEST

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

If a user story doesn’t make sense, use something else. Other examples are a job story or FDD’s features.

Want to learn more? You can take a look at our acceptance criteria blog post.

You have a project and need some help? Contact us.

Photo credit: Kaleidico