5 scenarios to avoid while writing User Stories
User Stories are often used in agile methodologies as an alternative to requirements, despite having an extremely compact and simple…
User Stories are often used in agile methodologies as an alternative to requirements, despite having an extremely compact and straightforward format, many times many mistakes happen, which makes it challenging to achieve the goal of User Stories. During this article I will present to you five mistakes that you MUST avoid, they are traps I’ve already fallen a couple of times, and now I want to share the learnings with you.
Remember that one of the principles of Scrum is: Communication over documentation. In other words, communication is the most important!
The question I ask is: What should we avoid when writing User Stories?
1 — User Stories must have a single purpose
What is the problem that generally happens? The User Story often contains the word “and,” for example:
As an e-commerce customer
I would like to filter products by price, category and size
So that I can find the products I want
Remember, the goal is to deliver value as soon as possible, when adding multiple requirements to a User Story, we do just the opposite. So always ask: does this User Story represent a single objective? If the answer is no, divide it!
The example given here can be divided into 3 User Stories, one for each filter type, price, category, and price. That allows the PO to prioritize that in different moments.
Mike Cohn explains pretty well how User Stories can maximize the value of business on his fantastic book User Stories Applied, which is a must-read. I would recommend the following article and video from him as well.
If you want to rock while writing User Stories, you must follow the principles of INVEST, take a look at this post.
Don’t write User Stories that have more than one goal.
2 — Avoid words that do not generate a single understanding
What does that mean? These are the famous expressions such as: performance improvement, availability, fast and so on. Avoid these at all costs, when you notice that you are falling into this trap, ask: how can I measure the result? For example:
As an e-commerce customer
I would like to view products more quickly after a search
So that I can optimize my time
The words “more quickly” in this User Story can be understood in different ways; it can be 3 seconds for one person or 1 second for another. So a better approach would be to write User Story directly in a measurable way! For example:
As an e-commerce customer
I would like to be able to visualize the products in maximum 3 seconds after a search
So that I can find what I want faster
So Product Owners, write only measurable User Stories, please!
3 — ALWAYS refine the User Story with the development team
The central part of a User Story is not visible, as it represents communication with the team. For this, the Product Owner must present the User Stories to the team and refine it together.
Remember, User Stories are not requirements, they are an invitation to discuss a problem, so the PO should not define solutions but rather presents the problem to the development team, and together they define the approach to solve the problem.
A widespread scenario is that the refinement will not be carried out with the team, when this occurs, you can be sure that problems will come!
Once again, I need to refer Mike Cohn here as he wrote a great post saying: “why the three-part of User Story template work so well,” that is clarifying.
A User Story is only ready to be part of the Sprint after being discussed with the team, never before.
4 — Breaking User Stories in a way that don’t generate value
This approach is a traditional discussion between the Development Team and the Product Owner. The PO may bring a User Story for discussion, which the implementation of it requires Front-End and Back-End, then the team asks: “can we split into 2 User Stories? Front-End and Back-end.”. The answer is no, but why?
Our focus is to generate value to the business instead of finish User Stories that bring nothing, if we split into 2 User Stories, they only deliver value once integrated, since separated they will not bring anything to the business. We should always ask how the business gets benefits from each of the outcomes of each User Story? No benefit means the User Story cannot be divided.
I would be curious to understand why do the teams want to split User Stories like this. Generally, because the Team Members like having the User Stories assign to a single person and be able to go through the process and reach the status of “done,” then burning the story points. Be careful; this is another trap, Scrum Teams must collaborate as much as possible, meaning that individual performance does not matter; what matters is the result from the team.
Therefore Product Owners must be ready to explain to the Development Team that the focus is always to maximize the value. If the User Story fits one Sprint cycle, then it can be prioritized, and the development team can split into sub-tasks in a way the work is divided into the team members. However, the User Story only finishes once all the acceptance criteria are met, meaning that it is usable by the end customer.
This topic is incredibly important. Therefore I would recommend you to go deeper, here is my recommendation for you.
Product Owners, don’t fall into the trap of writing User Stories that bring nothing.
5 — Forcing tasks into User Stories
A common mistake made by so many POs is: writing everything as User Stories. There’s a myth that the Backlog is compound entirely by User Stories, so let’s take a look at what the Scrum Guide says: “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.” pay very close attention; the Scrum Guide does not mention how the Product Owner should do it. We define how each task is better described.
I am a big supporter of User Stories, but as POs, we should evaluate when to use and when not to use. Sometimes there’ll be tasks that they would be forced if written in the User Story format. We need to understand that sometimes not using the User Story is better because we can avoid wasting time. The point is, the product backlog must contain items that are understandable by the team.
Here is an example of what not to do:
“As the CEO, I want three instances of the shop, so that a downtime of a single instance doesn’t bring the shop down.”
That could be written like: “Set-up load-balancing for the site.” So be careful with too much focus on User Stories where sometimes just some keywords would be enough.
There’s a fantastic article related to this, it was recommended at Scrum.org as a preparation for the PSPO II exam, you should take a look at it. Another excellent post related to this post, you can find it here, which I agree, not everything is a User Story, pay very close attention to it and avoid mistakes!
A great Product Owner focuses on the art of maximizing the work, which is not done, meaning that we must avoid waste.