What is User Story?
So, user stories! Undoubtedly, it is one of the main pillars of agile development and an essential tool for a product manager.
One of the tenets of agile development is the idea of breaking large developments into smaller chunks called stories. On the road to becoming a Ninja Master as a Product Manager and delivering value to customers with your product, you will have to take care of backlog and the user stories it contains.
But what is a user story?
To answer this question, let’s break this concept up into parts:
History, in this context, is “an oral or written presentation of material in an artistic form.”
User Is a person who owns or uses something at will, that is, a person who uses a computer, software, systems, or computer services.
Thus, we can say that the user’s story is a written narrative about the use of the system.
When we talk about agile development methodology, the user story is a tool that helps shift the focus from detailing system requirements to discussing them.
This is usually done using sentences that say the satisfaction of the requirement, for example:
how
Let’s give some examples of common stories to illustrate?
As a marketing manager, I want to know the source and mechanism for obtaining information about what caused the purchase on our site in order to understand which communication channels are best suited for the implementation of our product.
As a company leader, I want to know the average revenue for each product sold in order to decide where to invest more or less.
One of the benefits of following this model is that the storyteller is forced to focus on “WHAT” rather than “HOW” —the latter is the responsibility of the development team.
When creating a new story, the author should always focus on describing his needs and the goal that he is trying to achieve with its help. This allows the team, after listening to the story and not being constrained by the proposed solution attempts, to be free to create or propose the best alternative to solve the problem.
Who are the characters or persons in the stories?
These are the end users of the stories. They are the ones who often write or request them.
In the examples above, we use the marketing manager and the head of the company as the actors, but the participants can be everyone who is related to your product, the end customer, the internal user, the external user, the PM himself (product manager), etc.
Is PM only supposed to write stories?
Definitely not. The PM acts as part of the product development team and serves as a storyteller that can come from the client, other stakeholders (project stakeholders), or even the team itself.
The PM’s job, however, is to make sure the stories are well described and contain enough information for the team to easily understand. It is on the basis of a specific user story that the team will plan their work and assess its complexity.
Bad user stories
To get the gist of this statement, let’s look at some examples of mis-written usage stories?
A) “The download button is missing.”
B) “I would like more product information to be displayed on the attached screen.”
C) “Include more images.”
One way to turn bad stories into something useful is to use method 5 Whys ( 5 “Why“)… It also helps the author to be more prepared and to correctly describe their next story.
Hypothetically, let’s pretend I did this with the first story (A) in the examples above.
Problem: “The download button is missing.”
1st. Why?: – “So I can download the reports.”
2nd. Why?: – “So I can use the data in excel”.
3rd. Why?: – “So that I can cross-check information with data from other sources.”
4th. Why?: – “So that I can provide a complete report with information on sales and income.”
5th. Why?: “The board needs accurate sales and earnings information to make important investment decisions for the company.”
With this information, the original story could be improved, for example:
As a BI analyst;
I want to export data from XYZ report in CSV format;
So that you can provide the Board of Directors of the company with accurate information about the sales and receipts from the sale of our products.
Acceptance criteria
Keep in mind that a good user story also has clear acceptance criteria.
Acceptance criteria, as the name suggests, are the criteria by which a story can be accepted or rejected.
They are a set of instructions, each of which gives a clear pass or fail result — for example, a checklist that identifies functional and non-functional requirements.
The acceptance criteria in the end result is a “Definition of Done” and essentially well done.
Here’s a tip for writing good acceptance criteria – you need to think about how to demonstrate the functionality when it’s ready. How will it work? What steps are needed for this?
Using this idea and the previously mentioned story model, we could define some acceptance criteria:
As a BI analyst, I want to export data from the XYZ report in CSV format to provide the board of directors of the company with accurate information on sales and revenue from the sale of our products.
Acceptance criteria:
– When you open the XYZ report, at the end of the list of results, you will see a button with which you can download the report in CSV format;
– When you click on the button, the download starts automatically;
– The file is exported in UTF-8 format to be compatible with currently used formats;
Of course, all of this can be much more complex and contain more steps. In fact, the number of criteria is not limited. It all depends on the size of the story in question. However, it is clear that it will not be “Agile” if it is a story with 423 acceptance criteria.
Translation prepared as part of the course “System Analyst. Advanced”…
We invite everyone to an open lesson “Business and systems analysis as preparation for testing the quality of a software product”… In this demo tutorial we will discuss:
– Why do we need User stories to write test cases?
– How do system requirements help fill test cases?
– What is a test model and what does it consist of?
– How is the test model formed and filled?
