statuses or tasks - best practice


I've to implement few quite complex business processes in jira.

The requirement is to be able to track the time spend in each status and show it in a visualised form using kanban boards.


So now I've got a around 5 processes with around 10 steps each.

It all works pretty well but I've ended up with extra 50 jira statuses in the global JIRA configuration....


An example of one process is the recruitment process - having all the business statuses a business user will only have to create one card - like "Hire JIRA Developer" -  and that works pretty well.


Using generic JIRA Agile workflow (todo, in progress, done) would force the user to create multiple cards with some components (to indicate status step) - a user story and multiple of subtasks.


The end business users like the one card approach as they don't have to create and maintain multiple cards.


So what do You think which approach is better and what are the pros and cons?


I don't want to end up with 500 statuses in JIRA as there is no possibility to group it.

Its a pity that there is no possibility to define local project statuses....


1 answer

1 accepted

1 vote
Accepted answer
Peter Bengov Community Champion Jul 07, 2015

You choice sounds more suitable to the process you have described. Managing several tickets is a pain developers, think of how this can affect non-PC users like from HR.

Moreover, several tickets means more workflows, more issues types and so on - this could end up in a maintenance nightmare. 

What I would suggest doing with the statuses, though, is name them to be more generic, so you could use them on several projects with ease. For example:

  • Instead of using the Train Employee status for the HR project. You can name it Training and later use it for other projects as well.
  • The same with taking into account a working template: Pending Approval, Waiting for Approval, To be Approved should all be merged. Use one template for all your project, that way the other admins in JIRA will have a easier time too.
  • If you have several teams in one process, sometimes you can use a support-like naming: initial evaluation, development, verification, escalation.

BTW, using Kanban, you can just rename the columns to be more understandable names for users, while the status "behind" the column has a slighter different. 


Sounds reasonable, But some of the statuses may be quite specific to the business process and can't be defined as generic. I've been wondering if it may be a good idea to prefix them like RECRUITMENT_specific_status1 or REC_specific_status1 That way I could separate those from the reusable ones. What do You think?

Peter Bengov Community Champion Jul 08, 2015

I wouldn't go that way. Mostly because JIRA will trunc you long names, so users will usually see stuff like "RECRUITMENT_sp...", which gives them no value. I would add to each status a description, which can be done from the global statuses management page. This will allow you to document for which project/propose the status is used for.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,752 views 18 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you