Best way to mark an epic (and its tasks) as On Hold

[Vitor Elias]

Hello everyone.

Me and my team need to find a way to mark an epic (and its tasks) as on hold. By doing that, we'd also hope that statistics generated through dashboards could disconsider that epic while (and only while) in that status.

I understand I could simply establish an "on hold" status and filter, but what I need here is that statistics are taken into consideration while that epic is rolling, pause counts and clocking if we mark it as on hold, and that start counting and clocking again when (and if) we bring it back to any of the other statuses.

Besides creating a status, we also thought of flagging. Either way, the needs would still be the same, pause metrics/statistics, and continue from where it stopped if unflagged.

[Bill Sheboy · Accepted solution]

Hi @Vitor Elias  -- Welcome to the Atlassian Community!

There are a few ways to solve this, some depending on whether or not "on hold" is a regular part of your team's workflow.  If it is, please consider investigating that to decide how to improve.  Until then...

• You could add a label indicating "on hold" and exclude it from filters used for reporting...and possibly even your board
• You could do the same with a component...
• You could create a status for on-hold.  The problem with this one is that the board's filter creates the input for reporting. Some reports allow you to use an additional filter to remove items; many do not.

Best regards,

Bill

[Vitor Elias]

Hi Bill, thanks for your quick reply!

"on hold" is not a regular part, and hopefully won't occur much. We're talking about situations where clients put a hold on the transaction and my teams doesn't have much to do about that.

That being said, evaluating your options I'd say all of them should work, and I actually thought of them.

But, as I said, the reason that makes me worried here is how to pause (mark it as on hold) and get back from where it was paused (mark it back to regular statuses). Do you have any inputs about that?

Thanks again for your help.

[Bill Sheboy]

Hi! 

One of the reasons I suggested labels or components is that it is a quick change to return to "off hold": you delete the label or component.  You just gotta find the issue to make the change, probably using search if the issue isn't visible on the board.

Noting that you said "on hold" doesn't occur often, what do you think of this idea: do nothing to remove it from the board or reporting?

• When an exceptional thing occurs, like being on hold, treat it as an exception and use it as an opportunity to learn
• What happened to create the need to put it on hold
• How could we measure how frequently we put stuff on hold, and the subsequent impacts
• What could we do to anticipate the situation and prevent that in the future

__Bill

[Vitor Elias]

Hi Bill.

My first sugestion was exactly that, exclude from the dashboards' statistics and metrics the epic that was put on hold. But even though those shouldn't be many, the team leader requested for a more certain and more automatic way of handling this exclusion.

Also, do you know if metrics such as: time in status, time to complete, etc can be paused when moved to a certain status or if flagged? If yes, that's great and solves my problem.

If not, could I structure any kind of automation for that?

[Bill Sheboy]

Those are excellent questions... 

I find the documentation on the built-in reporting to be incomplete on calculation methods. I do not fully understand what is and is not accounted for in some Jira cloud reports.  Clearly when you export the data to a spreadsheet for analysis or review the logs, the numbers do not seem to match always what is displayed.

This uncertainty is why I built the time-in-status tracking from scratch for the teams I support, using custom fields and automation rules.  Another route is to use marketplace add-ons which may better describe what they find in the logs. Either of those approaches will give you better control of what is being measured and shown.

[Vitor Elias]

I see, Bill!

I'll see about that on our first extraction.

Accepting your answer for the overall help! If you ever have, in the near future, any further inputs and/or insights regarding this topic, please share them with me.

Again, thanks for the help