Best practice for tracking ongoing tasks?

[Matt Wilkie]

How should things that go on for indefinite periods like participation in working groups, standards committees, and so on be tracked and managed?

These can't be issues that sit in a To Do or On Hold board, nor are they a match for an In Progress service request. They will be there forever. A "time to resolution" that only closes once a year only to start up again would be soul sucking. Yet they still needs to be tracked somehow as an ongoing commitment, something that consumes resources.

A working group meeting a month of 2 or 3 hours, plus effort between meetings for pre- and post- work of at least the same (there's not point in being involved at all if there isn't between work). That adds up to significant expenditure to be aware of and manage. We could add each meeting as it's own task, and then the same for each action item, but then there's no view on what the whole 'project' costs.

What's best practice for things like this in the Jira platform?

[Jacob Vu]

Hi @Matt Wilkie

This is a good question and having given it some thought, I'm wondering if your organization has Advanced Roadmaps available to use? The reason why I ask is that Advanced Roadmaps introduces a level in hierarchy higher than Epic, which would be the initiative.

You could potentially have the initiative be the individual working group, standards committee, etc. and then have Epics to manage work that comes out of the meetings.

If you don't have the ability to use Advanced Roadmaps, I'd think you could create an issue type for on-going work and have its own workflow that you customize. The stages don't necessarily need to be 'to-do', 'in progress', etc. but something that works better for what you're doing?

Hope this helps.

Jacob

[Matt Wilkie]

We do not have Advanced Roadmap. We might go to premium but we're a single small team at this time and the value of Advanced Roadmaps reads like it's oriented to coordinating multiple teams. I'm leery of introducing more complexity than we need. (Our parent org already has at least three extant examples of badly implemented tracking systems that are horrible to use. We're exploring Jira for our own team in self defense.)

I will look into a new issue type for on-going work with it's own flow. Thank you for the suggestions.

[Tracy Chen]

@Matt Wilkie what resolution did your team come up with for ongoing tickets? I'm currently considering the same thing for my team.

[Matt Wilkie]

We didn't come up with something that really works. We're currently discussing just not tracking things at all in Jira that aren't suited for it, rather than attempt to bend Jira like this. The other major category of items that don't work well are the little things: an hour responding to this phone call issue, 30 minutes in that impromptu hallway meeting.

These two categories: long and ongoing, small and unpredictable, still need to be tracked somehow, but not in Jira I don't think. It just adds too much complexity, and then we tend to avoid using Jira for things that are good in it. 

We're finding it very challenging to find a level of granularity that provides insight, and is thus empowering, yet coarse enough that attending to (feeding) the level of detail doesn't suck the life right out of us.

[HN]

Perhaps a solution would be something like creating releases you can then group your recurring activities under.  This would keep you in one tracking platform and you can set appropriate start and end for each one per year, quarter or month.  It would mean creating the new ones as soon as you complete the cycle of the one before.  Still trying to get this figured out myself but hope this helps.