As a Platinum Atlassian Solution partner we have a team of certified Jira specialists. They are experienced in helping a variety of customer in using Jira. An important part of helping our Jira customers is giving them insight in the correct use of Jira issue types. This has inspired us to write this blog, so you are able to benefit from our best practices.
The ability for Jira administrators to freely create issue types can sometimes lead to unwanted results. When issue types are misused this will result in standard Jira functionality not working as expected. Jira is already fitted with a set of default issue types that are normally a good fit for software development. If this is not the case in your organization, it should trigger you into thinking if your way of working would justify the creation of new custom issue types.
So what is the best practice then of using Jira issue types for software development?
In this blog TMC ALM will share some of it’s best practices in using issue types.
First an overview of the out of the box Jira issue types.
Jira Core default issue types
- Task – Task that needs to be done
- Subtask – Smaller task within a larger piece of work
Jira Software default issue types
- Story – Functionality request expressed from the perspective of the user
- Bug – Problem that impairs product or service functionality.
- Epic – Large piece of work that encompasses many issues. Epic definition can be found here (source: Agile Alliance)
Examples of incorrect use
Some examples we have witnessed at customer sites are:
- Epic’s treated as ever lasting activities with no end-date (i.e. “Software development”, “Technical debt”, etc. )
- Stories containing too much work to complete in a single sprint.
- TMC ALM TIP: Jira allows you to easily split a story in the backlog view by right-clicking on a story
- Creating related issues outside the Epic. The issue may not be released as expected. This way it will also fall outside the scope of your monitoring tools.
Result of incorrect use
So which problems are created when issue types are not correctly used?
- Jira Epic reporting will not be functional, since there is no start/end date the chart does not give information.
- Add-ons like Jira Portfolio will not be able to usefully plan, since there is no correct input data to base the calculations on.
- Large amounts of work assigned to Epics will make it difficult to identify the work items, plan and work accordingly.
An Issue Type Best Practice
One of the recommended ways to hierarchically use your issue types could be the following:
Epics should be treated as large stories that do not fit in a single sprint. Or span multiple project and/or teams.
Tasks are left out since they are – technically from a Jira point of view – identical to Story’s.
The Bug issue type can be retained as it clearly defines a separate issue type that has it’s own use.
In the next upcoming blog we will go into more detail on the use and handling of these, bugs, tasks and issue types.
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.
