Jira is a great tool to manage your roadmap and your backlog. One of the main advantages of Jira is that it has great default issue types and lets you create any other types you may need to make the most of your project.
Default issue types in Jira
Epics are 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. You can learn more about Epics in my post about the Product Roadmap in Jira.
User stories within Epics are new functional requirements that have a direct impact in a tangible user benefit, expressed in a way that puts the user and the value delivered to them in the center, instead of focusing on the implementation details. A user story is a standard way to define the users, functionality and benefit in one sentence. For the sake of brevity we are only writing the functionality part of the story in the title of the issue in Jira. User stories are defined and developed in Sprints.
Tasks are issue types used to track tasks that don’t directly result in a new feature. 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 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 users 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!
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 send an image or a video.
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, and the interface is self-explanatory, so I will not go into details on how to configure this. Jira issue types have a name, an icon, and issue fields. Use these wisely as you will be able to change the issue type for a given issue and only the fields you indicate will be visible for each issue type.
What issue types that can help organize your Jira projects?
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 plan? This way we can filter them out to go through proposals in recurring meetings or as we plan roadmap iterations, and we can already link ideas to user stories and tasks in our roadmap.
- 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
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.
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.