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

More than a ticketing system

Hi again guys!

My first post was just a lot of waffling as you could notice, so let's get to the point! I've spent the last few days thinking about what this post should be about and today I just made my mind: I'll start from the beginning... and the beginning is always a user requirement:

"Hey, we need a system that allows us tracking all our projects and tasks, helping us organising our daily work, estimating our work load, logging time against tasks and from which we can generate reports. And, by the way, the system is JIRA because I've heard that it's very flexible and scalable".

All in all, the request sounded very reasonable to me. After having used JIRA for a couple of years, both as a simple user and as a project administrator, I thought it was going to be quite simple. However, user requirements are often very simplistic in the beginning and not before you start showing them some drafts do you realise what they really need. Actually, when it comes to process modelling they need those drafts to define their own requirements.

This is the point where I wanted to get to. Of course, there was a part of the project consisting of software development (and JIRA is a great solution for that, including reports), but there was another team doing something completely different. This bit included complex workflows, check points where governance comes into play, a complex hierarchy of tickets and a very detailed level of reporting based on work logs, type of task, work log attributes and process key dates... lots of dates.

We achieved the goal - I wouldn't be posting this if we didn't :D - and the process of implementation has been fascinating. The overall conclusion is that JIRA is an extremely flexible tool (here the user was right), relatively cheap for the features provided and with a bit of time you can give customers a fantastic product for managing not only tasks but also projects.

So, is JIRA the best tool in the market for project management and process automation?

Well, I'm not saying JIRA is unbeatable as a multi-purpose solution because I haven't had the chance to test other applications out there. However I can affirm it can be very powerful in combination with some plugins (Agile, Tempo, JJupin...). It requires some learning time but it is worth the journey.

I will build on this idea of transforming a ticketing system into something much nicer in the next few articles :)

Keep your eyes peeled!

Sergio

Getting started

Hi guys,

This is the start of a new blog that primarily aims to share my experience of computing-related aspects such as business process modelling, reporting, quality control, governance or work load management.

From a technical perspective, the main tool covered in my posts will be Atlassian JIRA (here the reason for the blog's name!). However, much of the effort that I put into resolving those issues is not related to coding or anything geeky, but with functional aspects that any of you could understand. Because of this, wider discussions will be brought up and JIRA, among other software, will only be the underlying piece of technology offering a possible solution to our business problems.

It's all about to start! Keep your eyes peeled! :)

Hasta pronto!

Sergio, AKA "The JIRA man"