Jira is a great tool to manage your roadmap and your backlog, and it is the software of choice for many companies of all sizes.
As a scrum master, product owner, or product or project manager, Jira is probably a tool where you will spend a lot of time over your career. Mastering it and knowing how to get the most of it without investing countless hours navigating tickets and comments is an investment you’ll thank yourself for in the future.
One of the main advantages of Jira is that it has great default issue types: tasks, user stories and epics are helpful and used by most teams. Jira also lets you create any other issue types you may need.
Jira empowers you to create an optimal setup and your team to get more done, better and faster.
In this post you’ll learn:
- Default issue types in Jira, including advice and tips to optimize how you use them in your project.
- How to create your own issue types, with detailed instructions and screenshots.
- What issue types you can use to superpower your team, and how to name them and use them to make work effective.
You may also want to check other posts in the blog:
Default issue types in Jira
Epics
An Epic in Jira represents goals or initiatives that are developed over time through a series of tasks, user stories, and other work types and that result in an outcome.
Epics are the top level elements Jira uses in the Roadmap view, and the related work is displayed nested, as user stories or tasks in the levels below.
I like naming my epics after these outcomes, and focusing on the impact of the user stories I plan to nest under it. I regularly review my epics to make sure they still reflect the impact I expect out of out outcomes.
You can learn more about Epics in my post about the Product Roadmap in Jira.
User Stories
User stories within Epics are new functional requirements that have a direct impact on a tangible user benefit.
They are typically expressed in a way that puts the user and the value delivered to them in the center instead of focusing on the implementation details.
For example, a user story format for “Facebook SSO” could be “As a new user I want to signup using my Facebook account so that I can save time”. This is a long title and it would make it hard to scan through your backlog, so it’s common to shorten user stories keeping just the middle part in the title: “Signup using my Facebook account.”
A user story is a standard way to define the users, functionality and benefit in one sentence. I like to complement my user stories with some additional information that I’ve found to be useful after working with several development teams.
- Context about the current implementation
- Potential solutions for the problem
- Validation criteria
- Risks or open questions
- Design assets and reference docs
Using this kind of Jira makes it very easy to write release notes or to keep track of everything the product does for every user – just filter by this issue type, and there you go, a complete map of your users’ superpowers.
If you want to learn more about user stories, I created an entire course about them for LinkedIn Learning.
Tasks
Tasks are issue types that track changes that don’t directly result in a new feature. Some examples of tasks are updating software libraries, configuring databases, writing technical or support documentation, uploading translations, or updating design system components.
If it is not a user story or a bug, it’s likely a task!
As your project grows you will likely find that tasks represent over 60% of the work in your backlog.
This may be a good indication that you need to define more issue types to sort your work better. Keep reading to learn how to create new issue types in Jira and what are some new issue types you can use, in case you need some inspiration.
Subtasks
Subtasks can be nested under tasks or user stories. They are one of the most useful features in groups of more advanced users, but a real pain for beginners in Jira.
Analyze who will be using them before you decide whether or not to add them to your Jira processes.
An alternative is to let the team members use them to track their own work within an assigned issue.
Open subtasks block the closing of parent issues, so you need to remind everyone to be meaningful about this!
Bugs
Bug issues are used to track all product failures. They can have an associated severity, or indicate the component they affect: Jira lets you adjust fields for each issue type so you can add as much or as little metadata as you need.
As a rule of thumb, no bug should be added to the backlog without a description and it can be very helpful to attach an image or a video.
How to create your own issue types in Jira
If you have enough rights you will be able to create new issue types within your project.
You can easily find this function in the project sidebar..
- Select > Issues.
- In the left column, go to Issue types > Add issue type.
- Enter a name and description for your new issue type. Try to use language that can be understood by anyone in your team and keep it broad, so that it can be used to collect different types of related activities. I will tell you more about this below.
- Choose between a standard or sub-task issue type.
- Standard issue types are above the epic level whereas Sub-task issue types are underneath the Story level alongside subtasks.
- Select Add.
Jira issue types have a name, an icon, and issue fields. Avoid reusing icons, and use the color codes wisely and to your advantage. For example, you could use blue icons for engineering, yellow icons for ideas, orange icons for marketing… use whatever convention works for your team and take advantage of color to easily identify relevant task types when you filter or as you take a quick look at what’s ahead.
The best issue types to organize your Jira projects
Ideas
I like to use a different issue type for ideas that are not yet fully incorporated to the product backlog.
You may fear adding ideas to the backlog. In this case, you probably have a backlog in Jira, and one or multiple documents with ideas. Instead, why not create a specific issue type for ideas and have a single place to review your product opportunities? As a benefit, we can filter them out to go through proposals in recurring meetings or as we plan roadmap iterations, and we can link ideas to user stories and tasks in our roadmap at a very early stage.
- Go’s will be handed over to the product team for definition and become new Epics or User Stories or Tasks for an existing Epic.
- No Go’s will be moved to a future planning Epic, closer or further in the future depending on the priority or the confidence the team has with each initiative. Don’t delete ideas unless they’re duplicates!
Use idea names that are short, and focus of the user benefit and not in the feature itself or the implementation you suggest. For example, “Linking facebook” instead of “Add button to integrate facebook”. The way we resolve a problem can change a lot in the definition phase. When tracking ideas, aim to fill in the following info, even if it is as a very brief bullet point:
- Strategic Advantage
- User Benefits
- Proposed Implementation(s) or inspiration
- Technical Feasibility notes
- Known risks & open questions
Marketing
If a marketing task results in a reusable asset, why not make it easy to identify it in Jira? Using a marketing label can help differentiate this kind of work from more executive tasks. If you use Jira heavily in marketing campaigns, you may want to add an issue type for campaigns as well.
Documents
Similarly, some tasks are different in that they result in the creation of documentation. I think it can be a good idea to use a different issue type for this kind of work.
Too many issue types in your Jira project?
Yes, it is possible to end up with too many issue types. Use common sense and research how other people approached this. The Jira community forums, for example, are full of valuable insights from other users.
If you made it this far, you may want to continue exploring my blog
I created the featured image of this post with DALL·E
