User Stories and the Backlog: Attributes of a User Story

In 2001, Ron Jeffries proposed a “three Cs” mnemonic for user stories: Card, Conversation, Confirmation. I think this is a great way of talking about them.

First, let’s talk about the card. The original term card refers to a physical index card or sticky note and these can be preferable for collocated teams, but the card can also be a record in an Agile Lifecycle Management tool such as JIRA, Rally, or VersionOne. The card isn’t intended to capture all of the information about the work, but rather it acts as a token for conversation and collaboration. Here’s what one of those might look like:

The most essential part of a user story is the title. There are a few different common approaches, such as:

As a [user or persona], I can [goal to be accomplished], so that [value they derive from successful goal accomplishment]
Some individuals suggest putting the value first: “In order to [benefit] as a [user or persona], I want [goal to be accomplished].”

It’s best to take the time to work with your user experience and marketing teams to develop robust user personas that you can refer to in your user stories.

If you are tempted to make a system or developer the user—unless the feature in question is an internal developer tool—there’s good odds that the user story in question isn’t delivering value to the end users who are paying your salaries.

In most cases, the user story title will be insufficient to begin development. Most teams will also write “Acceptance criteria” or “Conditions of Satisfaction” to accompany the user story. This is often a bulleted list of functional tests or requirements that are checked to see if the user story will meet the user’s expectations (“doing the right thing”). You can also include any non-functional requirements that are specific to this story, such as unusual security requirements.

Some teams like to write acceptance criteria using the “Gherkin format:” Given / When / Then. I invite you to inspect this format and see if it’s helpful to your team.

Once the team has had a chance to discuss and refine the user story, they can provide a story point estimate for the user story which is added to the card.

Other items that teams occasionally track on cards are:

Any known dependencies that this user story is blocked by or blocks
Any due date that the team has agreed to try to meet (this should be unusual)
Any useful notes, diagrams, history, or context
What this user story explicitly does not address

Although not explicitly spelled out for every user story, the Definition of “Done” is incorporated by reference. These are the criteria that should be met for every backlog item and usually speaks to non-functional requirements such as quality, reliability, and security. This is also referred to “doing the thing right.”

Next, let’s talk about the conversation. This is where user stories really support the third Agile value: “Customer collaboration over contract negotiation.” In the old days, a product owner or analyst would sit down with a stakeholder and come up with a long list of “the system shall” requirements. They’ll then briefly review these with a technical lead before “tossing it over the wall” to the development team to faithfully execute. There’s an expectation that the requirements will be fully defined, and the development team will follow them carefully. User stories are different. Although the product owner is responsible for the development team having clearly-defined success criteria, developers are essential to their creation. In fact, we may have multiple conversations about the user story over its lifetime: at release planning, backlog refinement, sprint planning, daily scrum, and the sprint review. I tell product owner that they should never expect user stories to make it through a thoughtful review by their development teams unchanged.

Here’s an example. Suppose the user story is “As a skier, I’d like a hot cup of coffee, so that I can warm up on a cold day.” Seems innocuous enough, right? So the product owner brings it to the development team during Backlog Refinement. Well, how hot is hot? Perhaps one of the developers knows that caffeinated drinks actually make people feel less warm. This is why it’s so important to state the value you are trying to derive from your feature: your team may know of a better way to realize that value! By having this conversation, we might update the user story to refer to decaf coffee or herbal tea and add an acceptance criteria that the beverage be served at 125–155 degrees Fahrenheit.

The confirmation is that final set of acceptance criteria that emerge when the product owner and development team have had a conversation about the user story card. The development team confirms that the story has been done by running through the acceptance criteria—either manually or with automated tests—and demonstrating to the customer or product owner that they have all been met. All that remains to validate is that the user story also meets the definition of done, and then it can be marked as Accepted or Confirmed by the product owner.

Now you know what a user story is. What’s an epic? This is really quite simple: an epic is simply a user story that is too large to be done by the team in one sprint. It shares all other characteristics, so if you keep this simple definition in mind you’ll be well served.