nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira statuses best practices

Joan Andreu Juan Torrens

I have a colleague that likes to have as much statuses as situations can happen to issues in a Jira Work Management project.

In my opinion that makes the board view less effective. I trend to simplify statuses to a maximum of 6. For example, I prefer to have just one finished status (DONE) and use the resolution field to determine how has ended.

What I would like to know is if there is any guide or best practices article from Atlassian about that theme that I can read and learn from.

Thank you !

Accepted answers

MidnightExe

Hei @Joan Andreu Juan Torrens

maybe this one helps you out a bit? According to Atlassian, while Jira supports adding a status for every part of your team's process, it's important to note that each additional status and transition can add complexity to the workflow. To maintain agility, it's advisable to keep your process lean.

https://support.atlassian.com/jira-software-cloud/docs/best-practices-for-workflows-in-jira/

Tomislav Tobijas

@Joan Andreu Juan Torrens Sometimes less is better! 😅

My experience showed that most workflows can be optimized and that instead of having 20+ statuses, you can have around 7-8.

Things get unnecessarily complicated and this ends up with not so good user experience.
It's potentially okay if you have one or 2 complex flows within the organization, but if each team/project has those, the site would probably end up being too chaotic.

I remember reading or hearing one sentence from an admin who worked in an enterprise organization something like:

...after revision, we noticed that 90% of projects could use a simplest workflow which contained 3 statuses - "To Do", "In Progress" and "Done". And users were completely fine with that...

Again, how you'll implement something highly depends on the processes and policies within the company, but I would recommend trying to 'globalize' everything; especially when it comes to statuses, resolutions, custom fields...

If this particular project needs to have more statuses > fine. But don't name those statuses 'project-specific' and instead think of names that could be reused in the future (but, before that, try to reuse existing/system statuses as much as possible).

Cheers,
Tobi

All comments

MidnightExe

Hei @Joan Andreu Juan Torrens

https://support.atlassian.com/jira-software-cloud/docs/best-practices-for-workflows-in-jira/

Tomislav Tobijas

@Joan Andreu Juan Torrens Sometimes less is better! 😅

My experience showed that most workflows can be optimized and that instead of having 20+ statuses, you can have around 7-8.

I remember reading or hearing one sentence from an admin who worked in an enterprise organization something like:

...after revision, we noticed that 90% of projects could use a simplest workflow which contained 3 statuses - "To Do", "In Progress" and "Done". And users were completely fine with that...

Cheers,
Tobi

Joan Andreu Juan Torrens

Thanks a lot for your thoughts. You are right, every project needs a reflection but always thinking in reuse.

And sometimes maybe to-do, in-progress, done can work, but sometimes you need just a bit more.

Joan Andreu Juan Torrens

Thanks a lot for that article!

I will make sure my colleague read it ;-)

Darren_3xxj1j

I'm agnostic.

The Enterprise Coach part of me likes to implement Lean's "Value Stream Mapping" to identify 'hidden queues' within the end-to-end process. I was asked by a department to help identify bottlenecks in their process. By having 'waiting for review' rather than bundle it all in 'in review' and we can see that hidden queue ('waiting for review').

The Kanban part of me - especially limiting work in progress ("WIP") - could then assign a WIP limit to 'in review'.

Furthermore, just because a Jira item says it's 'in review' doesn't mean it actually is: we might have 50 items all 'in review' and this could be a lie: perhaps only 7 of those are actually 'in review', the other 43 are 'waiting for review' - they're not being tended to, so value isn't being added (cf Lean's Value Stream Mapping)

Re simplified Jira boards, we can have multiple boards each rendering the same information in different ways, depending on the desires of the individuals. So if we want a simplified 'To Do > In Progress > Done' board, we can have all the statuses between "To Do" (work has not yet begun) and "Done" (work has been fully done) mapped to the "In Progress" column. I've done this before, and it's simple to switch between the different views if I want to zoom in (at the cost of scrolling horizontally or zooming out in the browser) just to see what's actually happening.

And then there can be another (set of) board(s) that can just look at portions of the workflow.

With meaningful status values, we can tell at an instant the state the work is in: is it 'waiting for review' or is it 'in review'?

But as I say, I'm agnostic, and actually I'm experimenting as I type (which has led me to this post)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

board

status

jira-work-management

jira-work-management-cloud