User Story Rant

This post will demonstrate how to write a good user story using agile. What is a User Story, or more specifically, what are agile user stories?

A user story is a manageable chunk of work that can be completed in a small amount of time. The time could be two weeks, two days, or two hours. Most development teams run on a two-week cycle of work, and they develop based on the user stories they decided they could complete in those two weeks. A developer may bring four or five user stories to work on in the next two weeks. One story may take two hours to complete, and the other might take four days. Either way, the developer should only take on the work they expect to complete within that two-week block.

The word to focus on is user, not developer or stakeholder, or the boss, the USER. The user is usually the customer. So, the story must be written from the customer’s perspective. A user story is an informal, general explanation of a software feature written from the end user’s or customer’s perspective. I will use this opportunity to teach another acronym you may hear in the wild, HIPPOs — the highest-paid person’s opinion. A user is usually not the HIPPO.

A good user story should include the following elements:

• A user role: Describe the role of the user using the feature.
• An action: Describe the action the user needs to take to use the feature.
• A value: Describe the benefit the user will gain from using the feature.
• Acceptance criteria. How do you know the story was completed successfully?

In this YouTube Rant, I talk through some aspects of user stories and how to clarify them.

As an Amazon Associate, I earn from qualifying purchases. At no extra cost to the consumer, I get commissions for purchases made through links in this post.

Developers

Many software developers fall into the trap of making user stories from the perspective of themselves and not the customer. They may complain and say, “there is no way to put this into the user’s perspective.” Let’s face it, the mantra of “people over process” will always trump the current way of doing business. Don’t forget that. If the team understands the issue and the tasks are being completed, it may make sense not to be so picky about how the user story is written. That being said, many eyes are on these stories. Sometimes the HIPPO will look at them; other times, the customer may view them. They should be readable by the customer, and the customer should understand them.

Let’s look at this hypothetical example. “I need to provision a server to install an Oracle database.” That is not from the customer’s perspective. What’s a server anyway? Who is Oracle? Let’s try this from the customer’s perspective.

“I need to store the client information so that I can retrieve it later for review.” To do this, the developer or Project Manager (PM) could provision a server and have the developer install Oracle. The details are in the description, not the title. The customer knows exactly what they are getting and a way to store and retrieve the information they collect.

Examples

A poorly written user story in Scrum would be too vague or not specific enough. For example:

“As a user, I want the application to be better”

This user story doesn’t give any clear indication of what “better” means, what aspect of the application the user is referring to, or what specific features or improvements they want. It is too broad and not actionable.

Another example of a poorly written user story would not be written from the user’s perspective. For example:

“The application will have a new feature that allows administrators to view user data”

This user story is not written from the user’s perspective; it focuses on the development team’s goals and not the user’s needs. It does not specify who the end user is or what problem this feature is trying to solve for them.

A well-written user story should be specific, actionable, and written from the user’s perspective. It should clearly state who the user is, what they want to accomplish, and why it’s important.

An example of a well-written user story: “As a customer service representative, I want to be able to view customer information on the same screen where I am handling the call so that I can quickly and easily resolve customer issues.”

This user story is specific, actionable, and written from the user’s perspective. It states who the user is, what they want to accomplish, and why it’s essential.

In summary, a poorly written user story in Scrum is too vague, not specific enough, or not written from the user’s perspective. A well-written user story is clear, actionable, and written from the user’s perspective. It should clearly state who the user is, what they want to accomplish, and why it’s essential.