Write Kick-Ass User Stories in Jira

This article is dedicated to writing kick-ass User Stories. I’ll focus on answering the following questions:

What is a User Story and how can you write one?
How to work with User Stories in Jira?
What are story points and how are they used to estimate the complexity of a Story?
How User Stories differ from other software requirements?

An introduction to User Stories

Engineers love solving puzzles, implementing new technologies, and finding better, more optimized uses for their tech stack. However, at the end of the day, the software they develop is not a Rubic’s cube. There’s more to it than being a puzzle that needs solving.

For example, let’s say you have a couple of eggs, a pint of water, and a bit of flour. What can you make from this humble list of ingredients? Obviously a loaf of bread is the first thing that comes to mind. But you can also make noodles, pancakes, or crepes.

Having a User Story that defines a user (a very hungry me, craving for something Italian), their intent (who wants to make some Puttanesca just like nana used to) , and the desired outcome (to enjoy a delicious, home-made meal) will steer you to the correct recipe – you will be making spaghetti.

Obviously, knowing why you do the things you do is helpful outside the kitchen.

How to write User Stories?

If we were to go by the definition, a user story is an “informal, general explanation of a software feature written from the perspective of the end user.” They are helpful, because they give the team a clear definition of what needs to be done and why.

Most user stories follow a certain format: as a [type of user] I want to do [action] so that [benefit/value]. You can use it as a template or wireframe for writing your stories.

An example of a user story that follows this format will look something like this: As a user of the XYZ Bank banking app I want to temporarily edit the default credit card transaction limit so that I can make an expensive purchase.

This description of a user story adds a lot of context and clarity. The dev team understands who they are developing the software for, that person’s intent, and desired outcome. Having your user stories follow this format also helps communicate your vision and progress to the business people.

Note: User Stories aren’t restricted to external end users. You can have user stories that are relevant to people within your team or organization who are dependent on something you’ll be delivering.

It’s also not that uncommon to have users who aren’t even people. We’ve had cases when we needed to write them from the perspective of a database, where the database substituted the user. These types of stories are commonly used in #research tasks. Just remember that the user – regardless of it being a person or an object – still needs to achieve something so the format of the story formula does not change.

What is a User Story in Jira?

Software development teams rely on User Stories for project management – they serve as building blocks for Epics and even Initiatives in Jira. Engineers use the finalized stories to create detailed implementation plans that will include all the steps that must be completed in order to deliver said Story.

You’ll need to click on the “Create” button in Jira to create a Story.

From there you’ll need to create a new issue and select the story issue type.

Once selected – fill the Story with the story description. Jira has many fields for documenting stories. You may be actively using different ones based on the processes established in your company. Let’s focus on several of them for now.

Summary: This field is a brief, one-line description of your issue. Use it to show what the story is about. Example: Temporarily change card limit.
Description: You can use this field to add more details and context, add links and file attachments, etc.
Epic: This field is located above the summary. It shows the Epic a Story is related to.
Reporter: This field will show the person who has entered the Story into the system.
Assignee: This field shows the person who will be working on the Story.
Watchers: This field is used to show people who are “watching” (receiving updates when something in the Story changes) the issue. This field is often used for code reviews and QA.
Due Date: This is the due date or deadline for a Story.
Story Points: This field is used to visualize the complexity of a Story.

The workflow of a User Story

Most of the time the first batch of User Stories will be created and added to the backlog ad hoc. They will be pretty generalized and their objective will be to simply give the development a certain vector. This step is usually done by the Product owner.

These stories will be later refined during the backlog refining sessions by the entire team. You’ll add Acceptance Criteria to the stories. These criteria are needed to further define the story and add a bit more context.

You’ll also assign stories their story points – an agreed upon rough estimation of the complexity of a story.

The stories that are moved from the backlog into the Sprint backlog must be ready. By that, I mean that they must be immediately actionable. This doesn’t mean that you’ll need to define 100% of the Acceptance Criteria. But you’ll need to ensure that the team understands the story well enough to a point where they are sure it can be delivered. For this purpose, many companies use INVEST checklists for their Definition of Ready.

The following stage would be to move the issue from the backlog to the Sprint backlog. This is when the development team will begin their work on the feature and, once the story meets the Definition of Done, the feature will be released.

Here are some valuable tips for writing kick-ass user stories:

The user always comes first.
Putting the user first will be much simpler if you are using user personas.
Collaborate on your stories. While it is true that one person will most likely write the stories, your team will have a much better time if you discuss them before including them into the Sprint. This will inspire creativity and can offer a handful of fresh ideas on how to address the matter more efficiently.
Don’t get too carried away with creativity. Every user story must have a definitive business value rather than being an obscure use case.
Be descriptive enough when writing user stories. As I’ve mentioned before, a User Story is a general explanation of a feature and the details revolving around it should go to Acceptance Criteria. That being said, you’ll still need to clearly describe the user, their goal and intent.
Refine your user stories. Each of them must be clear, achievable, and testable.
Add Acceptance Criteria to your Stories. They might seem similar to User Stories, but they are not the same. A User Story aims to describe what a user wants the software to do, while Acceptance Criteria (AC) describe the conditions that a User Story must satisfy. In simpler words, Acceptance Criteria is a set of conditions that the software must meet in order to satisfy the user. In our example with the banking app, the inability to an invalid number or having a limit on raising the card’s limit would be considered Acceptance Criterias.
While there isn’t a universal size for a user story, they are – by definition – atomic. They should be small enough for a technical team to be able to implement them within a considerably short amount of time (you should be able to move it across the board during a Sprint). And, if there are two parts of a story, well, there should be two stories.

Pro Tip

You can use a Jira Checklist to document the core points of the Story, mentioning the additional tasks as individual checklist items.

Story points in User Stories

Engineers typically use story points to measure the complexity of a story. We use a tool called Planning Poker to assign points to a story based on effort, uncertainty, and risk.

This method of measurement helps the team understand the workload per sprint from seeing the story points in the backlog.

How does this work?

The team discusses the work they need to do before the Sprint begins. All of the stories are reviewed and assigned with story points based on their complexity.
When the team commits to a Sprint, we know the stories we will be working on as well as their “worth” in points.
The team burns down stories that have met the Definition of Done by the end of the Sprint.
Any stories that have not been completed are moved back to the backlog and then refined and potentially re-estimated.These stories can then be moved back to the Sprint if the team decides on doing so.
When this practice is consistent for each sprint – the team will learn their velocity (the number of story points they typically burn during a Sprint) over time.

Obviously, there are other ways developers can assign Story Points to their stories. One of the most common approaches is the Fibonacci sequence.

This sequence follows a pattern where each number is the sum of the previous two in the series. The sequence starts with 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, and continues in the same way. Using this sequence as the scoring scale is known as Fibonacci agile estimation, which helps estimate the effort required for agile development tasks.

This approach is quite useful as it limits the total number of numerals in the sequence and eliminates the need to debate over the nuances of complexity. Why is this important? Deciding the complexity based on a finite number of points is simpler as, at the end of the day, you are limited to either 55, or 89 instead of choosing through the entire range of 55 to 89.

The T-shirt method is also used to evaluate the complexity of an issue but it forgoes the concept of having points whatsoever. Engineers simply use T-shirt sizes like S, M, L, XL, and XXL instead of numbers.

User Stories VS Requirements

People often think that user stories are an evolution of software requirements that have adapted to agile software development. In reality, they are a type of software requirements.

Other types of software requirements include functional/non-functional requirements, use cases, scenarios, SRS, and business requirements.

Functional requirements describe how a feature should function. Here’s an example: An Admin user needs to log into the ABZ application’s Admin interface using valid login credentials.

Non-functional requirements focus on other aspects like security, reliability, maintainability, availability, and performance. 1000 concurrent users needing to log into the ABC application in 5 seconds would be an example of a non-functional performance requirement.

Both functional and non-functional requirements must be prepared by a Product Owner, Product manager, or Business Analyst for every feature before the development begins.

Use Cases document what the actions of a typical user they need to undertake in order to achieve something. This may sound similar to a User Story, but there’s a major difference. Use Cases are written from the perspective of the system. They often include much more details and clear feature, and system requirements. They also usually contain technical details for internal use.

The Business Requirements, or BRS is a document that defines and specifies the customer’s requirements.

SRS or Software Requirement Specification is created by a Business Analyst once the Business Requirement Specification has been agreed upon. These requirements are usually crafted with minimal collaboration between the development team and the business. SRS are similar to user stories in the way that they don’t typically include any technical specifications or a defined way of developing the feature. That being said, their content is still lengthy and quite comprehensive. Think of them as a way the business shows what they believe their users want.

User Stories are leaner. They have grown in popularity as more agile methodologies have dominated the development scene. The appeal of User Stories is that they are much more simple and intuitive. They follow the Agile manifesto and can be written by anyone from the business or the development team. User stories are continuously being written throughout the project. You can also update them at any time.

Using Smart Checklist with User Stories

While attaching a Definition of Done to a story is not a #must, having one is still among Jira best practices. It is not related to the content of your story, but rather a reminder of the processes you’ve established.

An example of a Definition of Done would be that the feature is deployed, QA has access to it, and it has been covered with tests. Given its nature, the same Definition of Done can be applied to multiple stories, so it can be wise to automate it with a template. Having a checklist template for these things saves you from a lot of back and forth between developers, designers, and QA engineers.

You’ll also be able to add the Acceptance Criteria and Definition of Done to each individual User Story item in the checklist. This way both your team and the Product Owner will have them clearly visible whenever a ticket is open.

Importance of User Stories in software development

Everyone who’s used a messy product with a convoluted interface can confirm that software engineers can benefit from putting themselves into their user’s shoes. However, this is not the only reason why good User Stories are important.

Just like a to-do list will keep a person focused on what needs to be done in order to succeed with a task, a good User Story will guide the team towards solving the pains of their users.
User Stories help everyone be on the same page. This frees the team to deliver results the way they see fit without any one person telling everyone exactly what to do.
User stories are written in simple, non-technical language without any jargon and complexity. This inspires collaboration and involvement from engineers and “the suits” alike.