Do you consider Waiting/On Hold to be in the To Do Category or In Progress?

[Jeremiah]

My question was originally posted by accident in Jira Service Management. So, I apologize for the cross-post, but I wanted to bring in the rest of the Jira (JWM) users. The topic continues to focus on SLAs and that wasn't my original intention. So, I'm posting here as well.

I'm building a templated workflow to reuse across multiple projects and maybe I've been at it too long, but it was clear to me at one point that a status of Waiting or On Hold was an In Progress Category and not a To Do Category.

But, now I'm second guessing myself. I can't decide if I should move those to the To Do Category or not. Because, technically, they aren't in progress anymore. 

I'm curious as to what the rest of you think or do. Please voice your opinions on the topic. 

[John Funk]

Hi Jeremiah,

I most certainly say it should be "To Do" and the reason is that when issues are in those statuses, no one is working on them. They are not "In Progress". Yes, someone started working on them so they are in progress in terms of that, but they are not in progress in terms of work advancing. 

But also, and maybe the biggest reason, is that Agile practice considers work in those states to be a contributor to Delay for the work. In fact, many, if not all, apps calculate To Do status as Delay. Or they should. 

Personally, I do not like those statuses. My recommendation is always to leave it in the "In Progress" status where it is being worked, but then Flag it. The reason for this is that, yes, issues that are Flagged are also considered to be contributing to Delay when they are Blocked/Flagged by apps. Also, if you move an issue into a Blocked status, when it becomes unblocked, where do you move it to? Now you have to go into the issue and look up the history to tell. 

Finally, you are moving issues out of the column where they are being worked and into a Blocked column. This causes the Time in Status and Days in Column functionality to no longer be valid. 

That's my two cents - but it's an uphill battle to overcome the normal of creating such statuses/columns. 

[Jeremiah]

Most helpful comment yet. Thank you! I hadn't considered the time in columns, but honestly haven't been using those. I was more concerned with the end user having clear visibility of the issue's position in the workflow. I like a tidy column so if it can't be worked on, get it out of there and move it back when it's ready. 

Also, I have transition screens that ask the user to explain why they are moving it to on hold/waiting. What are they waiting on? What issue is blocking them (if any)? When they expect to follow-up on this issue again. From there it would go to cancelled or back to In Progress. 

I appreciate your input.

[John Funk]

You could do the same thing with setting the flag - create a self looping transition on the status that has the Flagged field and requires a comment be added or a custom field be populated. If you are always going back to the same status every time you leave the Waiting/On Hold column, what you are doing would probably work. If you are getting to that column from multiple other columns, then things won't be so clear. 

[Bill Sheboy]

Hi @Jeremiah 

Short answer: Please use whichever values make sense for your team, depending if the states are "working" or "waiting".  I do not believe the differences in Status Category values matter for Jira reporting as the field has little-to-no impact on workflow, measurement, etc. within Atlassian tools.  When one wants more accurate measures based on flow, additional tools are needed, such as from the Atlassian Marketplace or exporting issue histories to report in log-parsing tools.

Please consider, what does your team's workflow look like and what do the states represent?

Ignoring Jira for a moment, if one wanted to map a process that had working and waiting (or buffer) states, there could be a workflow like this example, where the "working" ones are bolded.  People or automation may transition the issues, and no looping is shown in this example.

Ideation / Intake > Backlog > Refining > Selected > Building > Building Done > Validating > Validating Done > Releasing > Done (i.e., Released)

Some teams will add the "waiting", or buffer states, to Jira boards to improve process visibility or flow management.  Yet those do not necessarily help with built-in reporting...

When Status Category (i.e., To Do, In Progress, and Done) is set "correctly" for the different status values in a workflow, it may help create reporting when issues are exported or reported upon in a moment in time.  Status Category can also help summarize progress across different workflows (such as when different teams have different processes).

However, Status Category does not impact things like Jira report measures as the Status Category values are not enforced for accuracy when Status values are mapped to a workflow.  A reporting exception is one could "hack" Atlassian's interpretations of Cumulative Flow Diagram and Control Chart to use filters to show / hide different status values to see some measures better.

If the team wants to add additional states to their workflow, consider if they are "working" or "waiting" states.  You could use the Status Category to help indicate that, but it will take additional work / tooling to generate reporting to use that information.

Kind regards,
Bill

[Jeremiah]

Thank you for your input. Reporting on it is as big as visually seeing the colors (gray vs blue) for the end user. Conceptually, I'm really just looking for opinions on the matter. I really appreciate your response!

[Jeremiah]

Do you personally have an opinion?

[Bill Sheboy]

Again I suggest: please use whichever values make sense for your team, depending if the states are "working" or "waiting".

You and your teammates will better be able to answer that.  The people in the Atlassian Community are not on that team, and so we would be guessing or answering based on our own processes / workflows.

When I am helping a team, I coach them not to include "waiting" or "on hold" states in their processes.  Doing so makes delays a normal part of work, driving up work in progress (WIP), increasing the chances of errors / rework, and disincentivizing them from solving delays when they occur.

[Jeremiah]

….we would be guessing or answering based on our own processes / workflows.

That’s the whole point of this discussion ;) - Thanks for your input. 

[Valeriia_Havrylenko_SaaSJet]

Hi @Jeremiah 
That’s a great question, and it really comes down to how your team defines and manages work within your workflow.

From a general perspective:

• Waiting/On Hold statuses are often seen as part of the In Progress category. This is because the issue has typically been started, or is waiting for something specific to proceed, implying that it is still in the middle of the process rather than at the beginning.
• If your team uses these statuses to indicate that the work has begun but has been temporarily paused, then categorizing them as In Progress makes sense. It also keeps the focus on tracking active work and its progression.

However, if your team views these statuses as work that isn’t actively being worked on and wants to differentiate them from ongoing work, it could be argued that they belong in the To Do category.

Considerations:

• SLAs and Reporting: If you’re measuring time in status or using SLAs, it may be helpful to categorize Waiting/On Hold in a way that reflects your tracking needs.
• Team Clarity: Choose what makes the most sense for your team’s understanding of when work has truly started and when it’s paused.

I'd love to hear what others think as well, but I hope this perspective helps you in deciding!

[Jeremiah]

Thank you for your input!

[Jehan Bhathena]

Hi @Jeremiah 

Imho, I would consider these in the ToDo category.

Something that is in Waiting or on hold, cannot be picked up unless it's dependency is resolved, and would consider both of these as Blocked statuses in theory (i.e. no progress being made), but once the dependency gets resolved the ticket while being in the same status can now be actioned or in other word the ticket is "To Do".

While this is my way or understanding this may change with other use cases too, and would highly recommend reading thru the other posts where user's have decided to use which category for which status.

Would also suggest mirroring the status category you're using for Blocked Status (i.e. if at all you're using this status)

[Jeremiah]

Thank you.