statuses or tasks - best practice

Hi,

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

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?

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 Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,755 views 11 18
Join discussion

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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot