User stories are a key element of Agile methodologies in project software development. Thanks to them, the team knows why it works and how it will benefit the end user. This ensures coordinated execution of tasks and, as a result, faster achievement of SDLC goals. Modern project management teams prefer to work with user stories in Jira, the top bug-tracking system. Let’s talk about the peculiarities of such work in this article ⬇️
What Is a User Story?
This is a description of the functionality of a software solution from the end user’s point of view. A software feature written in simple language contains one or more sentences.
In other words, they are an Agile project planning tool. During the Discovery Phase, the team breaks down the process into individual user stories. Specialists decide at what stage to create certain features.
Agile user stories are successfully used in well known methodologies:
- Scrum. User stories are included in sprints and tracked during each stage with index cards on the Scrum board.
- Kanban. Stories are added to the product backlog and embedded into the process.
User stories VS functional requirements
Sometimes user stories are called — functional requirements. But they are not. They are the desired value, the result that the customer expects. Requirements have a complex structure and description. They will come later when the participants have discussed and agreed on all the ideas.
A user story defines a relationship between a task and the value to be achieved. User Story Mapping (USM), a well-known user path-based design approuch, combines several user stories. So,
What is meant by Story Mapping?
Visualization tools, such as sticky notes, create a user story map. Specialists conduct business analysis and design user actions based on a real scenario. Thus, a team can see the backlog through the user’s eyes in a couple of hours.
Jira software is often used to simplify planning and setting tasks. The digital user story format makes the processes available to all QA and development team members, project managers, and product owners.
All this makes it possible to create a convenient space to generate out-of-the-box ideas and coordinate the actual tasks. Let’s consider several arguments in favor of creating stories.
Why Write User Stories?
User experience is a central part of the entire development process. The point is to present the right context to the team. This is of particular importance to the project and positively affects the productivity of a whole team.
Agile user stories allow you to:
- Divide the project into small phases and track the results for each sprint.
- Properly prioritize Agile software development tasks.
- Focus on the needs of real users, not abstract objects.
- Make the feature context clear as possible for each team member.
- Be creative in finding non-standard solutions for a particular task.
- Facilitate close collaboration the technical and non-technical specialists.
Writing user stories facilitate discussion among stakeholders. Employees with different skills are involved in the dialogue. Moreover, the team can discuss nuances with the PO (Product owner) throughout the work. This adaptable method is useful for projects with frequent changes.
Thus, writing an effective user story means creating the basis for realizing a better user experience.
We will explain how to do this using Jira software below 👀
How to Create User Stories in Jira?
Jira is more than just a bug-tracking system. The tool has important functions to improve the efficiency of process management. Among them are also sprint boards and user stories themselves.
Atlassian emphasizes that a user story is focused on the user. Notably, it is not only about external end users. It can be a system user, an internal user (team member), or even a client. The main thing is that the story should reflect their needs and desires.
What makes user stories in Jira special?
Let’s note right away that the main component is an issue. This refers to a specific piece of work you have to do. Each issue is assigned a unique ID, making it easy to find in the system. To make the work more flexible, issues are divided into types.
One of these basic types is a story. To be more precise, it is part of the largest issue (epic). An epic requires several sprints for the team to execute, while a story requires only one sprint. Separating into smaller user stories increases speed.
To generate a new user story, follow five simple steps:
- Go to the new issue creation screen in your project.*
- Create a new issue and select the desired Project from the menu.*
- Set the Type – ‘Story.’ *
- Add some words to the summary field.*
- Fill in the description field if necessary.
You can also elaborate on the issue using formatting options. Here you can choose the style and font, structure the text, add links, etc. that everyone involved can understand it.
Jira User Story Template
If you’re looking for the most convenient way for writing user stories, check out this short and succinct formula:
I am like X want to Y to Z
What each component of the formula means:
- X: The product user, i.e., a person for whom the functionality is being built.
- Y: A task, action, or product property in which the user is interested (X).
- Z: The final business value that the actual user expects to receive (X).
- I (a person): The main question the team must ask itself is, Who are we making the product for? The implication is that we know everything about the user’s personality at this stage.
- Want: The description is about the intent of the person, not the feature itself. The main question is, What does the user want to achieve with this feature?
- To: Here it’s worth thinking about how a person’s intention fits into the whole picture. The key question is, What is the ultimate benefit the user seeks?
For a deeper understanding, here are a few examples where we point out the mistakes in the story’s writing and correct them.
#1: Example
❌ As a customer of a lending institution, I want to be notified when the status of my loan application changes so I can get my payments faster.
Do you think the story is correct? It’s worth being more specific, clarifying what status we mean.
Take a look at the correct version:
✅ As a customer of a lending institution, I want to receive text messages about the approval of the loan application to get payments faster.
It makes sense to prescribe other application statuses, such as denial of credit.
#2: Example:
❌ As a sales associate, I want to get into the CRM system easier.
It is hard not to notice that there is no answer to the question “Why?” here, which means that the value of the story is unclear.
In addition, words like “easier” are ambiguous and do not accurately describe the user’s intentions.
Here’s the right version:
✅ As a sales associate, I want to authorize in the CRM system by code to e-mail so I can process more customer requests per shift.
Example:
✅ As a remote team manager, I want the internal communications application to include file sharing for participants to collaborate in real-time.”
Are there mistakes in this story? No, everything is in its place in this example.
Jira users do not have to describe specific features according to this structure. Your team can develop a template based on their experience and use it for each project.
To write an effective story, you must follow a clear structure and use proven practices.
Jira User Story: Three Best Ways
When preparing user stories, you can use other methods to understand user needs and elaborate on descriptions. Some methods allow you to verify the quality of the description you create.
Three С
Participants write user stories on “cards” in a digital tool. Then there is active communication around each story, the goal of which is to dive into the details. Each team member and client must give their approval to this decision. Only then does the workflow begin.
Thus, we have the Three C’s method: Card, Conversation, Confirmation.
User Personas
The essence of the method is a detailed description of the product’s target user. The Requirements Analyst or Product Owner may be responsible for creating such a character.
The character card should contain as much detail as possible:
- the character’s name;
- place of work (role in the system);
- place of residence;
- marketing characteristics (hobbies, interests);
- tasks to be solved by the software;
- the purpose of using the product.
A set of characters helps to understand what each user wants and to prioritize user stories. Thus, if a feature interests two or three characters, it’s worth implementing it first.
INVEST-criteria
Criteria that allow you to evaluate the quality of the written user story:
- Independent. A story does not depend on the execution of other stories. You can achieve this through vertical decomposition and cross-functionality of the team.
- Negotiable. The team and the client discussed all the issues (priority, acceptance criterion (AC), level of data detail) and agreed.
- Valuable. A story has real business value. This value is characterized by the question “Why?” Ask it for every story to understand its meaning.
- Estimable. The team needs to be able to evaluate the effort to complete the story. Ambiguity in the description makes it difficult to know where to go.
- Small. The timeline for implementation should fit within the duration of one sprint. Dividing the story into parts speeds up the task and makes it easier to track progress.
- Testable. Each story should have its own acceptance criteria. The idea is to create a minimum set of requirements that are easy to test manually and automatically. For example, “output results in no more than 0.2 seconds.”
Now let’s discuss how to add more detail to your story:
Acceptance Criteria
This element helps to understand what you need to do to provide value. ACs show the function from the user’s point of view, provide insight into the business objectives, and serve as the basis for tests. Criteria are written in the present tense and have a clear pass/fail result. Use the description field in the issue creation screen.
Gherkin Scenarios
It is a language for describing system usage scenarios that developers, QAs, and businesses can understand. These scripts are suitable for describing acceptance criteria and help automate tests.
The basic syntax consists of Given, When and Then. The script can also be extended with And, But, Feature. This way is good for describing complex scenarios with different variants.
The only way to ensure the quality of the story is through constant discussion in the team and directly with the client.
Do Not Forget to Facilitate a Discussion
What is the basis for a story? It is information about the product users’ problems, needs, and desires. You can get it from different sources.
In general, there are three ways of originating an idea for a story:
- User feedback, such as customer support tickets.
- Discovery work, such as customer interviews or surveys.
- Splitting an epic/big user story into parts with a story map.
Jira creates a digital space for discussing an idea. Use wireframes, mockups, and diagrams to visualize important points. You can attach files to Jira issues and link stories to resources such as wiki pages in the Confluence database.
Now let’s imagine that you’ve created a Jira user story. What’s next?
How to Work With User Stories?
As a rule, the Author of the story is the client, project leader, or PM (Product Manager). They present it to the team during the sprint planning meeting. Participants jointly decide which stories they will perform at this sprint.
Other things happening at meetings:
- analysis of requested functionality
- selecting ways to implement it
- assessing the complexity of the story
- splitting up big stories
There are different ways to measure effort to realize a story: scores, planning poker, and story points. The latter method is the most effective, especially compared to person-hours. Reminder:
If a story doesn’t fit into one stage, it makes sense to include it in other stages.
A project manager adds stories to the backlog only when a team is fully convinced of its value. Other user stories not put in the backlog can be set aside for later (e.g., in the maybe later section).
Thus, Jira’s user story plays the role of project momentum, motivating the search for new ideas and ways of solving problems. The result of systematic and coordinated teamwork is the development of a new feature that the user needs most.
