Jira Time estimates and time tracking

[#1]

Hello! 

I am trying to setup a reporting on Jira for the time tracking. 
But i have some questions about the working and how to Setup. 

How we work; 
We have some analysts doing a high level estimate for the work to be done.
This is registered in the Original Estimate field in the EPIC.
Later on, the work to be done is populated in Issues underbeneath the EPIC.
And the progress of the work is tracked with the time tracking. 

But each person puts his time on the issue, and it doesn't seem to be related to the time tracking on the EPIC. 

How do you manage the time tracking inside of Jira? Do you have any plugins that you use to track the time for each Issue/Epic and compare it to the Original Estimate? 

Would love to hear from you experiences and how it is used.  

[Giovanny MACARTHUR]

I have seen Tempo time tracking for Jira utilized, but I don't have a lot of experience with it. It did seem to work well for the story level. I suppose it could be utilized to roll up to an Epic level as well. In fact, we might have been doing that at the time. I am no longer at the organization where I used it. Maybe someone here can speak more on Tempo. 

[Carl Valcke]

There is an Add-on  called EPIC Sum-Up light 

https://marketplace.atlassian.com/apps/1213331/epic-sum-up-light?hosting=cloud&tab=overview


But I was wondering if I was using Jira correctly before to go to an addon tool as we try to stay as much as possible by the book in Jira! 

[Kelly Arrey]

We use two apps for this:

• Structure Cloud by ALM Works - this lets us see the roll-up of estimates and time spent in a deeper hierarchy than just Epics & Stories (we use Features and Goals above Epics)
• Worklogs by SolDevelo - this lets us see time spent by user, by ticket, by day/week/month

Both support exports to Excel, which allows us to put the information together and get a good understanding of how our time is spent and how we can improve our estimating.

[Dan Graydon]

Jira supports a hierarchical roll-up of hours:

Epic

    Stories/Tasks

        Subtasks 

If all time is tracked at the subtask level then the total of the subtasks will rollup to the Stories  if you check the Include subtasks in the Time Tracking of the Story.   If you use epic links then the Stories/Tasks hours will rollout to the Epic.

However, if you add estimates to the Stories or Epics then this will be added to the estimates of the Subtasks which can lead to double counting hours and confusion.  

Our PO typically creates the Stories and provide a ROM estimate before handing over to the team.  Initially, the ROMs were entered into the original estimate of the Story and then we removed this when the subtasks and original estimates were created which was less then ideal.  However, we have since created a ROM Estimate custom fields which doesn't affect the roll-up.

We then compare the ROM estimates to the Engineering subtasks estimates provide by the team after reviewing the Story.  If there is a large discrepancy then this drives a conversation between the PO and the Team.  

During the Sprint the team burns down the hours on the subtasks and updates remaining hours as needed.  This provided us insight into how the Sprint is progressing through the Sprint and allows the team to retrospectively assess there estimating accuracy relative to actual hours which is gradually improving each Sprint.

Of course the burndown is only as good as the data that the team is providing which is a continual work in progress but overall this is helping us to become a more collaborative, disciplined, and predictable team.  We have a long way to go but we are improving as a team and that is the objective.

Hope that helps!

-Dan

[Josh Costella]

I would look into using Jira automation to add the values from the Stories to the parent Epics before going the plugin route.

https://support.atlassian.com/jira-software-cloud/docs/automation-triggers/#Automationtriggers-Worklogged

FYI, the screenshot included is not a tested solution but more to show there are ways to move the work log data from the story to the epic. 

[Adam _SoftwarePlant_]

Hello @Carl Valcke 

Taking into consideration your needs related to tracking the time spent on the child tasks, as well as the overall progress of the parent tasks, I believe that BigGantt/BigPicture plugins may come in handy. Both offer the Gantt view, which you can configure to show and calculate dynamically the progress of the tasks, and also to display the progress - either in a separate column in the tasks WBS view or on the taskbar directly on the Gantt timeline:

I also highly encourage you to take a look at our documentation page, where we described this functionality in a wider aspect:

- Task Progress 

When it comes to BigPicture, apart from the aforementioned Gantt module, it is a strong PPM tool as it offers a variety of other modules which are extremely useful when it comes to managing your projects - including Resources, Board, and Reports modules - whichever methodology you currently use.

Hope this helps!

Cheers,

Adam

[Mykenna Cepek]

We use Tempo Timesheets, and it handles roll-up great -- not only to Epics, but to orthogonal elements that they also support (Accounts and Customers).

Beware: some solutions assume that all time logged to an issue relate to the Assignee of an issue. There can be team use cases where reassigning an issue might be part of a team's process (e.g. for a code review), or for other reasons (e.g. multiple people worked on various aspects of an issue). Within Jira, Worklog Entry records are specific to the user who logged the the hours -- but some solutions roll-up based on assignee instead (not based on Worklog Author). So be sure to do a Proof Of Concept to clarify that things work as you need in this regard.

[Ramiro Justet]

Hi @Mykenna Cepek 

You say : "We use Tempo Timesheets, and it handles roll-up great -- not only to Epics, but to orthogonal elements that they also support (Accounts and Customers)."

I have Tempo Timesheets with Jira Cloud as well, and the Original Estimate and Time Remaining values have no relationship to each other. That is, the epic values are not updated when creating a story or logging hours in those stories.

Maybe I have something wrong configured or I didn't understand what you wanted to express?

Thanks

Please disregard this comment. It does indeed work with Tempo Timesheets. 

[Mykenna Cepek]

Hi @Ramiro Justet. To clarify, my comment was addressing the original question "How do you manage the time tracking inside of Jira?".

Tempo Timesheets focuses on the logged time (aka "Time Spent", a total of the "Worklog Entries").

The "Original Estimate" and "Time Remaining" values in Jira have value for reports and work tracking (e.g. BurnUp/BurnDown charts, Sprint/Release/Epic progress, etc). But Tempo doesn't use those two fields at all.

Tempo's focus is to answer questions like "how much time was spent on X?" very flexibly. X might be a Story, an Epic, a Customer, an Account, etc. We also use it for reports like "How much time have individual users logged this week or month?". Tempo's great at aggregating time logged.

You'll need to use other techniques if you want metrics related to Original Estimate and/or Time Remaining. Jira has a variety of built-in reports that do a reasonable job on some basic use-cases for that data.

Hope that helps!

[Kelly Arrey]

Hi @Ramiro Justet Structure for Jira, from ALM Works, handles rollups for Original and Remaining Estimates very well. ALM Works was recently acquired by Tempo, so it will be interesting to see how they integrate in the future.

[Ramiro Justet]

Thanks @Mykenna Cepek !

[Ramiro Justet]

Thanks for the information @Kelly Arrey