The truth behind User Stories

User Stories in Scrum Guide

You have probably heard about User Stories at least once since you are reading this text.

Many people working in IT consistently associate Product Backlog Items with User Stories or “the bigger ones”, Epics.

In this article, I would like to explain what User Story is and how they should be used to define requirements.

We'll start by pointing out that User Stories aren't in any way associated with Scrum. They are not mentioned in the Scrum Guide. However, they're a fantastic way to present business requirements without diving too deeply into technical details. Their simplicity and versatility make them widely used in software development.

What are User Stories?

When we refine our Product Backlog, our goal is to have the highest priority items as atomic and precise as possible, while having those with the lower priority bigger and not detailed at all. We don't want to spend much time specifying them since we may not even work on them in the future.

We refer to larger and less precise items as Epics. They represent basic functionalities that we consider implementing in our product. Usually, they may require even a few weeks of work, meaning they are too big to fit into a single Sprint.

The User Story consists of a card and the Acceptance Criteria.

Card is an explanation of a specific function that would be valuable to an end user or client. It should explain what users' expectations are and that explanation should fit a small paper card.

The second part of the user story is a “conversation” that describes interactions between the designers, stakeholders, and developers.

The final component is acceptance criteria. They are going to help the Scrum Team to determine the value that the feature brings and define whether it is done or not.

Difference between good and bad User Story

Well defined User Story should look like this:

As a [user]
I’d like [an action]
So [value].

As a User [define what kind of user], I want to perform the action to get some value.

As an example, a well-defined User Story could be:

"As a customer of an online store, I would like to be able to log in to the system to have access to information dedicated only to me."

What are the bad examples in that case?

“A program must be written in Python.”
"Graphics must be completed in Photoshop."

Why are they bad? In the majority of cases, it won't matter to the client whether the image was created in Photoshop or Gimp. What matters to him is the final result. It is exactly the same with Python.

What are Acceptance Criteria?

For our User Story:

"As a customer of an online store,
I would like to be able to log in to the system
to have access to information designated only for me."

The Acceptance Criteria may be written on the back of a paper card and may appear as follows:

• The user can log in to the system by clicking the "login" button once valid login and password have been provided.
• The user may log in to the system if their account has been created and was neither disabled nor removed.
• After logging in, the User should have access to his profile and purchase history.
• In case a not-existing login is provided, the user will be notified that they used a wrong login or password.

The previous User Story is detailed and as such could have already been refined into smaller tasks and implemented.

Even Product Backlog Items can be written on a paper sheet, it doesn’t need to be done this way. We have an enormous amount of tools available we could use nowadays, especially digital ones. Scrum Guide doesn’t mention User Stories at all so it doesn’t matter what tool we use as long as we decide on something and stick to it. Thanks to that our product will be more customer-centric than ever.

User Stories misconceptions

People tend to make a lot of mistakes while working with User Stories. It is a shame because they can be easily avoided.

The most popular one is made by the Product Owner when he focuses more on the functionality rather than the goal itself.

Let's see with the following User Story:

“As a Scrum Master,
I want to know what is in the Scrum Guide,
so I know how Scrum works.”

It looks nice, right? Not really. Let’s think about it. Why should the Scrum Master know what is in the Scrum Guide in the first place? For the sake of knowing it? It seems shallow and meaningless. It could work in some cases but not being focused on the goal may lead to some issues in the future.

Now, let’s consider the following User Story:

“As a Scrum Master,
I want to know what is in the Scrum Guide,
so that I can help teams create fantastic products."

Does it look better to you? We have a goal now. Scrum Master wants to know what is in the Scrum Guide so he can help his teams to create great and valuable products.

Another mistake one may make while working with User Stories focused on implementation or detailed flow. There is no need for it. The Scrum Team is full of professionals that could figure it out.

Lastly, imagine there are no Acceptance Criteria. Writing a good User Story may look easy but there is no way for the team to know if the scope was implemented correctly when there is no checklist. Nothing that could help them verify the feature. Expectations should be clear and precise.

Do it right

There is a lot of misconception when it comes to User Stories. People like to focus on technical details and implementation instead of focusing on the goals. Moreover, once they start working with User Stories, they try to put it everywhere. We shouldn’t do it. Use them only where it makes sense.

"If the only tool you have is a hammer, you tend to see every problem as a nail." - Abraham Maslow