User Story Title

Question

When creating a user story work item in a tool like GitHub or, Azure DevOps, Should the ‎“As a user, I want” phrase be used for the title, or should it be placed in the description?

Answer 1

TL;DR

Titles should be short and pithy, but meaningful. Think of them as communications shorthand that give the team a handle to refer to, not as lengthy descriptors. The story labels should make it easy to differentiate stories from one another.

Effective Story Titles

What constitutes a good or bad title will vary a lot based on your organization and project. However, there are generally some common elements.

Bad titles are often too short to be meaningful, or too long to be easy referents. They are at best useless, and at worst they create unnecessary cognitive load. Consider the following examples:

1. Task A, Task B, Task C

   While there are occasionally use cases for ordinal or non-descriptive titles, it simply begs the question of "What is the actual task we're talking about?" In other words, it's not descriptive enough to provide context when referring to the work item, or to differentiate the tasks from one another.

2. "As a Stack Exchange participant, I want a simple title that conveys useful information so that I can attract good answers."

   Titles like this are too long to use as referents. They also represent a needless duplication of the contents of the user story. Do you want to repeat this title (and dozens of others like it) every time you talk about a work item, or when planning work? Probably not. It's simply not effective as shorthand or as a conversation placeholder.

Now, contrast these items with some better examples for the same work items:

1. Database Table Update, Rails Version Upgrade, Deploy Release 2.0

   You don't have to dig into the meat of these work items to get a sense of what they're about. A good user story will contain additional context, but these types of short descriptions usually provide enough context to identify who should look at or discuss the story within the team, and make it relatively easy to differentiate the stories from one another. In other words, they are great labels.

2. "Identify optimal title length."

   Here the title acts as a summary of the story's contents. You can tell at a glance that it's probably a story spike or research task, and that it's about titles and lengths. Because it's a short but descriptive handle, team members can say "I'm working on the title length story today," and be easily understood by the rest of the team.

There are as many ways to write user stories as there are teams using them, and the most effective way to label or title your stories (if you even need to do it at all) will depend on your processes, tools, project plan, and communications objectives. There's no objectively "best" way to title user stories, but it's pretty hard to go wrong with clear labels/handles for communications shorthand.

Answer 2

It doesn't really matter. Just do what seems suitable for your processes.

In my experience, if you are using an electronic board, the "As a user I want" phrase will be too long to be shown directly on the board and get truncated to a meaningless "As a user I want to..." (or slightly longer, but not long enough to really tell what the stories are about). In those cases, it is best to have that in the description and use a few keywords for the title.

Answer 3

I agree with what the other answers has commented: The title should be descriptive to know in a glance what will happen when the story is released. I would like to add some advice I use to write it, and it's use "When released, this story will...", as follow:

"When released, this story will... " > "Send an email to Service Delivery when the order is delivered"

Related to the feature description, you may set a Feature title with that described bellow to give more context:

Feature

As a Service Delivery member 
I want to receive an email when an order is delivered 
So I can check that the delivery worked correctly.

Answer 4

A title must be precise. The simpler the better.

The prefix phrases like 'As a user', 'As a system administrator', 'As a business owner', 'As a developer' etc. are best suited for describing the acceptance criteria of the story.

A simple title will make the story easy to refer to or look up.