I’ve never been a huge fan of the as-a-user approach to user story naming. It’s not that I never use it. In fact, I even used it once last week:

As a user, I want an edit button next to the issue icon in the search results so that I don’t have to click all over hell in order to edit something in Jira.

See. A well formed user story name following the as-a-user convention. And it really gets the point across.

I’ve never been a fan of consistently using this approach, but I’ve always had a problem putting a finger on exactly why. It is a pretty good approach. And its hard to argue against consistency. Seriously, it is.

Then, last week, I read Artem Marchenko’s post Why I don’t use standard user story format that much and things suddenly clicked in place.

In his post, Artem argues that standards for standards sake aren’t useful and that the as-a-user approach is not a highly-tuned tool to train the team to focus on the end user (if they don’t buy into the idea this won’t help). He does specifically call out one benefit he sees from the as-a-user approach, and that is when similar functionality within the software may have different stories to benefit different users.

And that’s when it crystallized for me.

We should name user stories (or features, or any other deliverable) based on the conversations we want to have about them. This way, we can frame the correct context of our discussions around prioritization and requirements.

If we have a system with many roles and one product owner (or customer), the as-a-user approach may make a lot of sense. However, if we have a group of stakeholders who prioritize the stories, it may make more sense to establish a pattern that highlights the benefit of each story. A pattern, for example, that starts with the benefit to be derived from the story:

• Reduce tech time spent on maintenance activities by building an ad hoc query browser for the operations group
• Increase conversion by removing the optional fields from the account creation form

One can argue whether each story will actually achieve its stated goal, but isn’t that a huge part of prioritizing stories and defining requirements?

In the absence of any other need to frame the conversation, I use Story Titles, which must be short and specific. For example:

• Schedule Group Appointments
• Self-Service Pixel Management
• Workstream Hierarchy Tab on Sprints Page

You don’t get all the details, but there’s enough information to clearly distinguish one story from the other. The naming approach behind Story Titles has two goals: (1) to communicate a clear sense of what is being done, and (2) to be short enough that the name is memorable and used consistently. This approach is essential for activities like the Feature Building Workshop.

Just as one-size-fits-all fits no one well, no one approach to naming user stories is always right. In order to determine the best story naming convention for a specific situation, you must know how you want to frame the conversation.

Comments (0)

Write comment

Show/hide comment form