How to use JIRA for time tracking as a Business Analyst?

[Sorcha MacDonald]

I work as a Business Analyst and I am often filling in for Product Owners in the Agile process. This means that I am often walking in at least partially blind to a situation with no idea what I might uncover once I lift the lid off of the proverbial can of worms. This also makes it impossible for me to reasonably estimate how long it will take me to find out what the requirements actually are. What I ended up doing on the last project I was on was estimating how much time I could spend working on something in a sprint. So ultimately, we had the metrics for time tracking. However, my time tracking task doesn't really fit into the workflow that we use for tasks and it all feels kind of fake / misleading because I am not actually finishing anything the way that developers are. I was hoping for some ideas from the community as to how they have addressed this. I have some ideas, but nothing that is really hitting me as a good solution. 

[Jack Hunter _HeroCoders_]

Hello @Sorcha MacDonald,

Welcome to the time tracking nightmare :)

The first question I would ask first is: "Why do you need to track time?". Is it for payroll purposes, charging a customer, tracking project health? The answer can determine the way that you want/should track time. 

There are many concepts available in Jira.

If you don't finish the task completely then you can have a few Jira issues that are always open or in progress and next you can log work against these issues.
If the team uses Scrum and Jira Sprints, then you can close the issues at the end of the Sprint, and recreate at the beginning of next Sprint to keep the time tracking data accurate for the Sprint. 

When comes to logging work, you can do it manually with "Log Work" Jira functionality, e.g. at the end of the day if you work mostly on one thing. 

If you jump between issues more often or forget to work time manually, you can try to automate the time tracking process with the plugin. 

Clockwork Automated Timesheets app available on the Marketplace lets to start/stop a timer with a press of a button. It saves the hassle of calculating/remembering the time spent on an issue. 
It also allows tracking time automatically - timer starts when an issue goes to any status of "In Progress" category and stops when the issue goes back to "Open" or "Done". 

Or, maybe you don't need to track time at all? 

Let us know more about your case.

Cheers,
Jack

[Sorcha MacDonald]

Hi Jack!

Thanks for taking the time to reply. In answer to your first question (why do we want to track my time), it is in an effort to understand how 'expensive' my efforts are and to start to get some degree of predictability out of the data. For example, let's say we have an epic which will cover a function that involves searching the database for employee history and returning results. At the start of the initiative, this is all I know. I don't know what data the end users want, where that data is stored, how it will be presented, if it needs to be cleaned or transformed etc. Since I don't know the answers to any of these questions, I have no idea how long it will take me to figure it out so I can help Arch and Dev build a useful product. But I can estimate that in a 3 week sprint I can spend 20 hours on it. I make a task in JIRA, estimate the time at 20 hours, and manually track my time against it over the sprint so I know how much I have actually spent on that task. At the end of the sprint, I close the ticket. For the next sprint, I create a new task with a new estimate. I repeat as needed. (This is what I really did in a recent project.)

By doing this, we will, at the end, know how much time I spent gathering requirements on a specific topic. This serves two overarching functions:

1. By knowing how many hours I spent on something, management is able to figure out a corresponding dollar amount so they know the cost, in both hours and dollars, something our management is very interested in knowing.

2. If we repeat this activity across epics, and we are good at our relative estimations of work (story points, S/M/L etc), then it will give us some way to more accurately predict upcoming effort. However, it is important to note that this will still be very rough, as a user definition of what is simple may not match what we uncover as we go, particularly if there are unforeseen technical complications. These rates will also be pretty variable based on my knowledge going into a situation and could vary significantly between BAs of different skill sets. In short, it may provide some insight but is unlikely to really be accurate. 

When the aforementioned project ended, we did a post-mortem / lessons learned. One of things we have been taking a hard look at is how we utilized JIRA. My organization doesn't typically work in an Agile fashion, so this was all new and unfamiliar and we felt there were a number of things we could have improved on.  Going through this process, I have done a lot of reading about how Atlassian recommends we use JIRA, the purpose of specific fields etc. This led me to the conclusion that while what I was doing was ok, it doesn't really fit well with how I perceive the rest of the team to be working and how their data/metrics would be interpreted. 

In the context of Agile, it seems to me that my work is almost 'pre-work'. For example, if we were in a position to have our business owners come in and relay requirements in an intelligible manner for Dev/Arch/QA, then we might be able to create a reasonable product backlog and do estimation activities as a group etc. We can do that once I have done the requirements gathering though. So from that perspective, my research feels like it is outside of that process. I am learning how to represent the needs of a product owner. (We know this isn't ideal but it is our current reality.)

My concern is that by entering my tasks as time tracking only, I may be skewing the data / metrics we get out of story points / time estimating / time tracking with the rest of the team. For example, is it really an estimate of velocity when the ticket is not accurately showing how much work there is?

Further, my tasks don't really need a workflow either. In the project I was working on, I just started and ended my tasks. Essentially, I skipped the intermediate steps. 

To sum up, I think gathering data about my work is useful, I just don't know if putting it in JIRA is the right way to go. I could track it elsewhere, which may make the actual 'building' work cleaner as far as data and metrics go. However, that means that the information would be in more than one system, which isn't thrilling me either. 

Hope that helps to clarify what I was asking!

Sorcha 

[Jack Hunter _HeroCoders_]

Hello Sorcha,

So:

1. You cannot use estimates reliably because you don't know exactly how much time you will spend on the issue. That's OK. With this approach, it would be harder to predict the project timeline but you are the only one working this way so is acceptable I think.
2. You use different workflow than the rest of the team and you don't need Story Points. I can see two solutions here:
   
   1. Try to find another task which is similar when comes to the time required and give your task the same value for Story Points as this other task. 
      If the project is big enough than inaccuracy should not influence the project reports much. However, this is not the prettiest solution.
   2. Create another Agile Board in the project only for your own, so:
      1. Your time estimation and log worked will be part of the project - management will see your time data in project reports.
      2. You won't interfere with your team board and their velocity charts/progress.

From what you explained, I think solution 2.2 could work well. 

Overall, with the apps like Clockwork Automated Timesheets, you can improve the time logged accuracy which is usually desired in projects that use time tracking. This way you and your management can get a better overview of the project costs and the process/workflow efficiency.

Good luck with your Jira adventure :)

Cheers,
Jack