How to work with user stories in Jira

Jira is a good tool for managing the product backlog of work items for the development team. User stories are a type of item in the backlog. It makes sense to use Jira for working with user stories.

However, it is important to keep a tight backlog with only relevant items, and user stories often go through an early phase where it is not clear whether they are relevant.

Therefore, use your judgement, and only add user stories to the backlog in Jira when you want the team to spend time on them, i.e. when you start to feel quite confident that it is something you would want to build.

User stories

The low-down

User stories are a way to describe product requirements. They have the form of natural language, and take the point of view of a particular user.

User stories originated around the turn of the millennium. Early proponents where Alistair Cockburn, Kent Beck, and Ron Jeffries, also among the original signatories of the Agile Manifesto.

A common format for writing user stories is "As a _, I want to _, so that _".

The user story lifecycle

User stories can emerge during early problem discovery, where they ideally come as a story from an actual user.

They then evolve further during discovery and refinement, where they are re-written and merged/split as well as extended with details in conversations with team and stakeholders (and ideally with actual users as well).

Then they mature as they go into delivery and release, where they are implemented by the development team as a series of tasks to fulfil a set of acceptance criteria.

After that, they live on as working software that will generate further feedback and insights that trigger yet new user stories.

Benefits and pitfalls with user stories

+ Helps team and stakeholders think with the end user in mind

+ Helps team and stakeholders speak the same language

+ Very simple and flexible format, possible to slice, split and merge

- Risk of becoming a formula rather than a mindset, like a haiku poem that is "correct" as long as it is formulated the right way (with anti-patterns such as "As a system I want to..." or taking features that has never been mentioned by real users, apply the formula, and simply hope it will deliver value)

- For the individual developer, a user story by itself, without the cross-team conversation, is less descriptive than a traditional requirement

Jira Software

The low-down

Jira is a tool for the backlog of work items of the development team.

It originated as a competitor to Bugzilla, a system for tracking and handling reported issues and bugs. One way to think of Jira is that it is a database of such "issues". Each issue can have a number of properties, including description and priority.

As Jira developed into a tool for not just bug tracking but also software development it also added types beyond bugs (e.g. user stories) and boards (e.g. sprint boards), among other things.

How product teams use Jira

Most product teams use some version of Scrum, and for them Jira has a neat functionality to take a part of the the main product backlog and turn it into a board with the sprint backlog.

In the sprint backlog teams often both put tasks to implement user stories and discovery tickets, directly or indirectly related to user stories.

Benefits and pitfalls with Jira

+ Established and common. In fact, it is the most commonly used such tool (our research suggests that as much as 40% of PMs use Jira).

+ Very mature and stable. If you can think of a feature, it is probably there, especially thanks to the vast number of integrations (including this one)

+ Links with the code. Developers like that Jira links tickets in the backlog to the underlying code (e.g. in git).

- A little bit clunky. It can take several seconds to load each single issue. Thus, it can take quite a bit of time to look at information across several user stories, or to merge or split user stories.

- Risk of the backlog becoming an enormous hairy monster over time. This since it is easier to add tickets to the backlog than it is to review and prune items in the backlog in Jira.

How to best work with user stories in Jira

When to put user stories in Jira

A large number of user stories emerge early in the process and then go through many iterations, splits, merges, prunings. One of the pitfalls of Jira is the relative ease of adding new issues over iterating/pruning them. Because of this, there is the risk of a too large backlog. Any PM can agree that it is hard to see the forest for all the trees when working with a product backlog with many hundreds of items.

To avoid this, PMs must be vigilant at holding back things from entering the backlog and diligent in cleaning out things that no longer fit in the backlog. That way they can ensure the health of their backlogs.

Therefore, as a PM, you should continually develop your product management skills to improve and then use your judgement, and only add user stories to the backlog in Jira when you want the team to spend time on them, i.e. when you start to feel quite confident that it is something you would want to build.

How to not lose user stories that don't go into Jira

How to best keep track of an idea that doesn't make it to the backlog depends a bit on where the idea emerged.

To generalize, there are three ways user stories emerge

1. As direct incoming feedback from users (or employees).

2. Through discovery work with users.

3. When breaking down an epic or a bigger user story.

If the user story emerged as a direct feedback from a user, e.g. as a customer support ticket, but was still not deemed as relevant enough to go into the backlog, then it is often best to let it stay in the customer support system. This system should be possible to tag, search, and refer to - so that it can be known if the same idea emerges several times.

If the user story emerged as an idea from an employee (e.g. from something like an "innovation funnel"), but didn't make it to the backlog, then it is good to have something like an "icebox", where you can put such ideas and then later if something changes that make them more relevant, find them again "thaw" them.

For ideas that emerge during discovery work (e.g. in user interviews, user tests, or surveys), it is good practice to write notes, and make sure they are tagged and searchable, but also combine them with and link them to something similar to what Teresa Torres calls an "Opportunity Solution Tree".

That way, you have a structured and visual point of reference to go back to, also for the ideas that have not yet made it to the backlog.

When working with breaking down epics into smaller user stories, a good method to use is the "User Story Mapping" by Jeff Patton.

A core part of that method is that is that it is OK to add a lot of potential user stories for each step, without having to commit to build them. Because of this, it often makes sense to add only the user stories from first one or two iterations of a user story map to Jira. The other user stories can stay in the user story map and be referred to later.

To continue to add details to the user stories in epic and to have clear point to refer to so the ideas don't get lost, it often makes sense to work in a feature document (also known as a product requirements document, or a PRD). For such feature documents it is valuable to use an outliner, as that allows for a combination of structure and speed. Delibr is an outliner specifically made for this use case, and also integrates seamlessly with Jira.

Example

To illustrate the point of what to put in Jira and what not to, let's take an example of a common feature.

It is common to build a feature to let users add comments. This typically arises from a need for users to interact or collaborate. When this comes up, users often come with a wish list of adjacent features, like "mention user", "reply to comment", "resolve comment", "upload images to comments".

In almost all cases, uploading images to comments is implemented way later than the first comments functionality is implemented, if ever. And if it is, it is because users repeatedly keep asking for it.

Therefore it is most often better not to add that story to the backlog, but rather to keep it in something akin to the "maybe later" section of the Comments epic document, and then next time the team takes a stab at improving the comments functionality - they can review the thinking in the old epic doc as they go on to make a new iteration.

‍