The more you want, the less you get (time tracking)

One of the things any project manager would love is a perfect break-down of the time worked on their projects. As a JIRA analyst (but this can be applied to any other tool allowing time tracking), you might want to warn your customer or manager that being too ambitious can play against them.

Certainly, time-tracking works really well in JIRA. When combined with the Tempo plugin, it gives users some very nice options to log time (both from the ticket and from a timesheet). Also, Tempo upgrades this feature by adding “attributes” to work logs. For instance, we could be logging 3 hours against the ticket X, belonging to project Y and selecting a type “Customer meeting” in our work log attribute “Type of work”.

It could be argued that instead of using work log attributes to detail the type of work, we could simply create different types of tickets (Customer meeting, Documentation, Testing, Finance…), but… do you really expect people to create a JIRA ticket every time they have a meeting or every time they prepare some slides for a presentation? That’s the end of productivity!

Another option would be to automatically create a bunch of “typed” tickets every time a new project is created. This way, for project X, there would always be a ticket for documentation, a ticket for meetings, a ticket for finance, etc. It sounds good, doesn’t it? I thought the same before realising that in a particular department they weren’t going to create a new JIRA project for each of their so-called “projects”. Basically, their number of projects was so big that they needed one only JIRA project (working as a box) with many sub-projects inside, represented by what they call “Master Ticket” (this will be covered on a future post). In this case, the solution above wouldn’t work.

So, it seems that we are constrained by the complexity of work log attributes for end-users and the complexity of projects in that department… and don’t forget that our customer is looking for a very detailed report on hours with many dimensions: project, type of task, type of work within the task…

At this point, it is important to prioritise your requirements. The ideal world exists in our minds only. In my opinion, it is vital that end-users feel comfortable using the system as the information they enter will be the only source for any report on hours we want to run. If users look at logging time as that awful thing I have to get through, it is very likely that they won’t be very accurate. Also, depending on the type of business, an extremely detailed break-down of people’s work might not be a primary need so, as an analyst, it is crucial to make your customer aware of these risks.

I hope you enjoyed it! Thanks for reading and, you know, keep your eyes peeled!

Cheers,

Sergio

AKA The JIRA Man