02/4/20

What’s in a (Story) Name?

When building a backlog of stories within your project or program, naming conventions are incredibly important in saving costs and time during your Agile ceremonies and development. While story names don’t have to be a novel necessarily, they should allow the reader the ability to identify immediately what the content of the story likely is, and the likely work behind it.

Traditional user stories should always have the expected main components, such as story description, acceptance criteria, associated tasks, size, and assigned team members. However, the importance of story titles is often overlooked in a sprint (and even) PI planning. Naming conventions or titles can provide tremendous value in understanding the true effort behind the feature. Since stories should deliver pieces of workable/testable/demonstratable code, a story name should represent or explain what is functionally in front of the code, to whoever is reading it. To illustrate the point, let’s quickly examine a use case where the team is developing a mobile experience for logging in to an application:

Feature Name: Mobile Device – Application login and Authentication

Story Names:

1. Clicking the mobile icon on the device home screen

2. First-time user login

3. User device authentication/registration

4. Entering credentials to the log in screen

5. Landing on the app home page

In the case above, Stories 1,4, and 5 have clear story names that support the overall feature. Users can quickly figure out what should be behind the story description, acceptance criteria, etc.; the story is intuitive and links to the overall feature as well. It also explains the functionality that the user is trying to complete when they are in the process of using the app.
On the other hand, stories 2 and 3 are vague and could end up being much more significant than they might seem, especially when compared to the other stories. Story #2 is a full feature, while story #3 is likely an embedded story within feature #2. Story #2 seems to insinuate a series of steps that a user might need to complete for the first time when using their device. Just think about it: I need to install the app, open the app, etc. (without any errors). Story #2 could also be broken into smaller stories that accomplish the items needed to be completed for the story to be fully complete. So how do we re-write these stories to make sense, one may ask?

Feature (1) Name: Mobile Device – Application login and Authentication

Story Names:

1. Clicking the mobile icon on the device home screen

2. Entering credentials to the log in screen

3. Landing on the app home page

4. Logging out of the app (to the main page)

Feature Name: Mobile Device – First Time Login

Story Names:

1. Install the application to the device

2. Open app to the home screen

3. Click new user

4. User device authentication/registration (previous story)

5. Etc. (further stories)

In the second series of features, it’s much clearer to the fact that there is more work than initially specified or estimated. In the second supporting feature, the product owner or business analyst will have to fill out expected acceptance criteria for each one of the stories so the developers can appropriately estimate the build effort.

Stories with ambiguous titles or names can easily be underestimated and can lead to inaccurate planning within your Agile ceremonies. What may seem like a story that fits into a feature at first, may end up causing significant delays in work due to bad planning or analysis. Teams should charge product owners and managers, as well as business analysts, with making sure that story names represent the work they’ll be completing during development. While scrum teams can sometimes make up for this ambiguity, why settle? Accurately and precisely creating story names can save teams from affecting their burndown, splitting stories, or even ambiguous requirements and acceptance criteria.

Leave a Reply