How to manage issues in Jira Software

As the Platinum Atlassian Solution partner, we have a team of certified Jira specialists. They are experienced in helping a variety of customers in configuring and using Jira. An essential part of helping our Jira customers is giving them insight into the correct use of Jira issue types. It has inspired us to write this blog, so that you can benefit from our best practices. 

This blog is the 2nd part in the series on the use of Jira issue types (part 1 can be found here: on the topic of correct issue type use). In this blog we talk about how to manage issue types, sprints and backlogs in Jira.

How to apply issue types in Jira?

Below is a description of the default available issue types in Jira and what their most-used application is.  Jira allows for other custom issue types like ‘Initiatives’ (also explained here), but this is out of the scope of this blog. 

Also, for each issue type, different workflows can be applied. This can differ per client, but we often see different workflows per issue type. Where an Epic might have a more straightforward workflow (Todo, In Progress, Done), others might have more detailed workflows to cover all the scenarios. 

Epics

Epics should be treated as large stories that do not fit in a single sprint or take longer to complete when not using scrum. It can span multiple projects and/or teams.  Epics are different from the other issue types that it represents a group of related issues. There are also two dedicated reports: Epic Report and Epic Burndown to monitor the performance of your Epic(s). 

Epics are a special kind of issue type in Jira that are not visible on the backlog or boards. You can make them visible on scrum boards by configuring swimlanes. Epics are objects used for clustering and tracking the progress of it’s stories and tasks. Therefore, by default, do not show up in sprints as they’re a too big object to resolve in one sprint. 

• Epics consists of multiple issues, optionally from other projects
• Issues are linked to an Epic, via the Epic Link
  • An Epic link differs from a regular link in a way that it describes a parent/child relation for one purpose
  • Allows to group issues via Epic linked issues
  • Rolls up time estimates of Epic linked issues
• Are shown in the Backlog together with the release 

Note that Epics are not placeholders for time-related items but always have a beginning and an end. For time-related items, you typically use Release (Fix/Versions) in Jira where you can define start- and end dates.

Tasks and Stories

The technical difference between tasks and stories is minimal. Depending on how you apply Jira for your product development a use-case can be made for using tasks and or stories.

From our experience, tasks are often left out since they are – technically from a Jira point of view – identical to Stories. Tasks would typically be an issue type for items that need to be planned but do not directly contribute to your product.  From our experience companies define their own meaning for differentiating between Stories and Tasks.

With the introduction of Jira 7+ the issue types Improvement and New Feature where also introduced. They also have identical behavior and properties but only have different naming to describe their application. Because of this we will not address these issue types further on.

Subtasks

Out of the box sub-tasks do not contain the story point field. The idea behind this is to prevent micro-managing activities and so estimation should be done on a task level. Also note that sub-tasks behave in different ways then other issue types. Story points on sub-tasks are not taken into account and not displayed – by default – on the board. They are always related to a parent issue but can be defined at will.

Bugs

The Bug issue type can be retained as it clearly defines a separate issue type that has its own use. It does have, by default, the Affect’s Versions and Environment fields attached to the screen but no link to the Epic.

They do not have the story points, by default, added to this issue type. The rationale is that bugs do not add customer value, as they show up unexpectedly and are not ranked. On the other hand one could argue that the fixing of bugs can be more accurately planned using story points.

If needed one could also choose to identify internal and external reported bugs. This could either be done by an unique issue type or defining fields.

Managing issue types in sprints and backlogs

Epics

For planning Epics, you would apply the Fix Version/s or Release fields. An Epic, by default, will not show up in the sprint but does get displayed in the kanban (as explained earlier). Epics can also contain issues from other projects as well. Keep in mind that issues from other projects in an Epic can not use the out-of-project Fix Version/s or Release fields. Delivery and releasing of the Epic is managed in the project where the Epic resides.  Delivery and releasing of the Epics’ issues in other projects are managed in their respective projects. Atlassian has add-on for assisting with the alignment of multiproject issues in these Epics : Portfolio for Jira.

(Sub)Tasks and Stories

These issue types can be planned when needed. Subtasks are typically unplanned and not estimated as they can be created by team members to divide up the work.

Bugs

On this topic, opinions differ. In practice, we see a lot of different approaches on how to manage bugs in sprints. Depending on the culture or approach in your company, your implementation can vary.

Below are some options we have come across; there is no right or wrong here.

• An approach could be that solving bugs is planned in sprints. Example: 10% of the sprint time could typically be allocated for bug fixing. This means you would plan less than the reported Velocity in Jira. 
• Another could be to change scope, but this can impact the burndown. It can help to create a separate Kanban board to rank and prioritize bugs.
• Add Story Points to bugs to overcome the problem of the reported Velocity in Jira.

Additional information on how bugs can be handled in Agile can be found here: https://www.scrum.org/forum/scrum-forum/6660/how-defects-should-be-handled-scrum.  At TMC ALM we do not believe there is a one size fits all solution. We have assisted many companies in making the best decision on this topic. Of course we can advise you on what would be the most practical solution for your specific situation.

Contact TMC ALM

Do you also experience similar issues and don’t know how to solve them?

Contact TMC ALM for support or training on JIRA administration. 

Details can be found on our website: https://www.tmcalm.nl/