statuses or tasks - best practice

[eXtensi Admin]

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....

[Peter Bengov · Accepted solution]

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. 

[eXtensi Admin]

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]

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.