Report - Logged hours by project and user

[Gabriel Loroima]

I need to generate a report with the project's hours spent and user's imputations. Is there any tool that can generate this kind of report?

[Mariana_Pryshliak_Saasjet]

Hello @Gabriel Loroima 

You can try add-ons from the Atlassian Marketplace for logging work: https://marketplace.atlassian.com/search?query=log

Or as an alternative,  try a third-party add-on developed by my SaaSJet team - Time in Status for Jira Cloud.

It doesn't show logged hours but generates 7 types of time reports (it's helpful in your case too). Time in Status report shows how long an issue has been spent in each status. So you can get to know how long it takes to solve each issue.

Assignee time report shows how long a particular assignee has been assigned to each issue. It helps to understand the duration of issues resolving. Then you can export these reports as  XLSX or CSV files for further analysis.

HOpe, you find it helpful.

Best regards, Mariana

[Mykenna Cepek]

I'm going to assume you're talking about Classic (company-managed) projects, rather than Next-gen (team-managed) projects.

- - - - - - -

One built-in option is to use an Issue Search in the project (Project > Issues > Advanced Search), use a search similar to this...

project = "ABC" and type in standardIssueTypes() and status = done

...and ensure you're showing the "𝚺 Time Spent" column. You can further drill down (by modifying the SQL) to a specific sprint, or month, or whatever. You can also export the results as a spreadsheet if you want to process the data further manually.

- - - - - - -

There are a lot of options (some paid, some free) to help with this in the Atlassian Marketplace. You likely have (unstated) specific reporting needs, so it's impossible to give you a simple answer. Take a look at some of the add-ons to see if they show example reports that look like what you want/need.

- - - - - - -

I will suggest that you NOT try to use Advanced Roadmaps to gather this type of information. The "Progress (hours)" column might seem to offer the kind of "logged time roll-up data" that you want. But I'm here to warn you that it doesn't (too much detail to explain here).

- - - - - - -

Hope that helps. Let us know what you end up finding to work for you!

[Dave]

Hey @Mykenna Cepek ,

Would love to understand further the concerns about Advanced Roadmaps progress column to see if there's some improvements that can be made here. Are there specific use-cases where this doesn't work or do you feel like it's not accurately reflecting progress at all for some reason?

It's definitely fair to say that the progress is only reported at an issue level rather than as an aggregate of an entire project and that plans might not contain all issues from within a project so it would be good to understand further. Any additional info you can provide would be greatly appreciated to help us improve Advanced Roadmaps,

Many thanks,
Dave

[Mykenna Cepek]

Fortunately I wrote a 6-page summary of all the ways that Advanced Roadmaps disappointed us with tracking a series of efforts. I'll include just the bits related to the "Progress (h)" column below.

Note: we do not estimate work for the issues discussed here. 

• When epics are shown on the roadmap, what shows for this column depends on whether the epic has children or not:
  • If the epic has children, then the progress bar shows always all green (meaning "100% complete") which is wrong. Hovering over that for the pop-up detail will give an accurate aggregation of Time Spent for the epic + children + subtasks. If you are not using estimation, that pop-up also says "0 hours remaining", which can be extremely misleading to a leader/exec/stakeholder.
  • If the epic does not have children (a very valid use case for us), then the progress bar does visualize logged time vs the Original Estimate(s) for the aggregated issues. However, this requires perfect usage of that Original Estimate field for all issues. The hover pop-up in this case shows completely differently, calling out the "hours remaining" which is the opposite of the "Completed" hours that is primary for an "epic-with-children".
• At several points we noticed aggregated time discrepancies at the Epic level. I spent time tracking each discrepancy down, discovering these problems:
  • The "Exclude any completed issues after 14 days" default configuration (under: Plan > Settings > Source Data > Exclusion Rules) caused issues (and their logged time) to disappear from the plan. I set this to 365 days as a crude workaround.
  • The "Exclude Statuses" configuration was also set to "Done" (is that the default?), causing logged time to again disappear as issues were closed. I cleared this configuration field to ensure that time on all issues was aggregated, regardless of issue status.
  • Note that the above two configuration settings "fix" aggregated time, but now cause clutter on the plan, as ALL issues stay visible in the plan.
  • Other "Exclusion Rules" and "Removed Issues" configuration can also affect aggregated time. I have to monitor those settings to ensure someone else doesn't inadvertently use them. Since this aggregated time relates to budgeted/billable hours, it's important to get it right.

- - - - - - -

Our use-case initially seemed really simple.

We have a set of 10-20 "engagements", each represented by an Epic. Sometimes we needed to break that work down; sometimes we only needed "a place to log hours" (the epic). We had two primary goals:

• track aggregate logged time for each engagement (as the OP wished);
• visualize the start/end against a rolling calendar (this worked fine).

I added an "Engagement Hours" field to our Jira, which we set on each Epic. This was the total time allocated to the engagement. Our goal was to track aggregated logged hours (time spent) against this target. Because the "Original Estimate" field has a different built-in meaning in Jira (it's specific to the Epic as an individual issue, and has a metric relationship to the Time Remaining field), we did not use that field. We also were not estimating any of the work (only tracking logged time), so using an "estimate" field would have been confusing.

The various problems detailed above led me to eventually banish the "Progress (h)" column from our roadmap, and we have to find that aggregated data elsewhere.

[Dave]

Hi @Mykenna Cepek ,

Thanks for providing that detailed breakdown, I'll review it with our PMs and see what needs to be addressed here.

I did some experimentation and not everything seems to tally with exactly what you've described:

The progress doesn't seem to always show as done for epics without children, but rather reflects the logged ours on the issue. 

I do agree that the relationship between the "Estimate" field and the time tracking field on the issue details screen is not completely intuitive. When you initially set the estimate on an unestimated issue it will set the original estimate, and when time is logged via the issue it will be reflected as progress on the plan. Where it gets confusing is when you then adjust an existing estimate from the plan as this will extend the remaining time.

The pop-up is intended to reflect the overall progress of the epic and its children (rather than just the epic itself)

It sounds like this is not what you're expecting, but rather you just want the progress information to be related to just the epic itself?

Regards,

Dave

[Mykenna Cepek]

Your testing will better match what I'm describing if you leave the Original Estimate and Time Remaining fields blank. That's what I meant by "we are not estimating".

I realize that one common use-case for Roadmaps is for "planning". But our hope was that Roadmaps would also have value for "tracking" (independent of estimation). The latter is where we were disappointed.

[Dave]

Thanks for that clarification @Mykenna Cepek. As you say, Advanced Roadmaps is intended to be a planning tool, especially with respect to estimation and team capacity planning (although it also allows roadmaps to be created purely from manually provided dates). Its primary use case is definitely not expected to be as a tracking tool, however without estimates you can use the Progress (issue count) field which does at least give you an overview progress of the immediate children in terms of pure numbers (this works based on status category, not estimate).

Adding more tracking capabilities is unlikely to be something we focus on in the near future (although we expect to reintroduce more reporting, but I suspect this also isn't quite what you'd be after).

Regards,

Dave