What is the best way to time-track non-Project / "overhead" tasks ?

Question

What is the best way to enable time tracking for administration tasks that must be done - but are not directly associated with the development project?

Things like :  training, sales meetings, travel etc ...

Should I just set up a "bucket" of time in an admin project and log work against these tasks?   Is there a better way to handle this?

Ashley_Taylor · Answer

I find the 5/8 assumption works well for our team as well. We tend to average it out over the week expecting 25/40 hours project billable time. Some members end up tracking their full 40 showing non-billable time as a separate task issue type - but we don't require it.However, we do track our customer meetings as an issue type with typically 1-2 story points attributed (for prep and actual meeting time). Meetings our billable to our customers so relevant for tracking.

We use this model for working at home as well. On remote working days, members are asked to maintain the 5hrs of project billable time rather than an 8hr day.

Steven Hensgen · Answer

We had raised similar questions within our company running multiple projects within JIRA. Some of the time that we required team members to log were within the scope of the project but not related to a specific issue or task (e.g. Planning, Daily & Retro meetings).

While other lost time on the project was due to things like technical issues and other unrelated incidentals that we still wanted to be able to track so we could determine where a team members time was going.  This information was important to us as at the time we had a lot of work carrying over each sprint (Agile) & we wanted to generate reports in an attempt to determine the reasoning.

Initially we achieved this by creating a series of sub-tasks under a story within each project.  These sub-tasks persisted across multiple sprints & had names such as "Planning Meetings" however we found this approach a little tiresome to manage across multiple projects & made reporting across projects fairly complex and time consuming.

The end result for us was to create an overall project that stored all the miscellaneous tasks that we wanted team members to have access to & then to make logging time to these categories easier we added these categories to a menu item within the JIRA top navigation by creating a simple plugin (Misc Time Logging For JIRA).

Building on this we then added reporting to the plugin so we could get a break down of all the "other" hours not logged under the project itself based on a range of filters such as per project, sprint or user.

For such a simple thing it has made tracking lost hours a lot better for us & the end result was we could rectify (mostly) why we continually had sprint carry over.

Nic Brough -Adaptavist- · Answer

"Best" is really difficult to answer, because Jira is flexible and hence tries to fit in with your way of working, rather than you having to adapt to the way it does things.

I'd work backwards for this one.  What do you want to report on?  Are you going to end up requiring your users to put all their time in Jira so something like the Timesheet plugin can report on what they're doing?  Or is it actually for planning these non-technical tasks?  Or just reporting on them so you know how much time they are consuming?

I've seen it handled all sorts of ways though.  One place insisted on having timesheets that added up to worked time for developers, so they created issue types of meeting, client visit, and so on, and put them in the development project.  Another place had much the same, but put it in a set of non-development projects.  A third simply assumed 5/8ths (a developer is expected to log 5 hours of an 8 hour day as real work and do that accurately.  Then the other three hours are not tracked in any detail, but assumed to be meetings, travel, chatting to colleagues, coffee etc)