Counting # of Days spent per Engineer in an Epic

[mborinstein]

I would like to know how much total time each unique assignee is spending on all of their tickets within a given epic. I would like time to start counting when a ticket is moved to "In Progress" and time to stop counting when the ticket is moved to "Done". 

Let's say I pick up a ticket on a Monday and move it to "In Progress". I finish the ticket and move it to "Done" on Friday. I also pick up another ticket on Wednesday, and also move it to "Done" on Friday. I would want this to count as 5 days spent on tickets within the epic (as opposed to 8 days with the time double counting for each issue). 

Does anyone have any ideas on how to get this kind of count? Ideally I could pull a report for each epic that tells me this information per engineer but I am open to any approaches to this!

[Trudy Claspill]

Hello @mborinstein 

What problem are you trying to solve by getting that information? How will the information be used?

What would you do if a user was working on issues in multiple epics with child issues across epics in progress at the same time?

• In Epic 1 I put child issue A to In Progress on Monday and set it to Done on Friday.
• In Epic 2 I put child issue B to In Progress on Monday and set it to Done on Friday.

Does that count as 5 days in both epics?

What if a user moves an issue to In Progress and then is out of office for some days before setting it to Done?

Have you instead considered having the assignees use the Log Work function to log actual time spend working on issues?

If you go that route, be advised that Jira does not natively provide methods for reporting on time logged per user. It can only report on the total time logged per issue by all users that log time against that issue. It also does not automatically roll up time from child issues to parent epics, though you could develop workarounds for that.

Otherwise to report on time logged per user on child issues under a given Epic would require a third party app.

[mborinstein]

Our engineering leadership would like to know how many full-time engineers are working on each epic to get a more exact sense of how much effort is being spent on each of our initiatives. So in your scenario where there are 2 epics that would count as 5 days for 1 epic and 5 days for another epic under that same engineer but because we'd be looking at a per epic level that wouldn't matter as much. You're right that it doesn't account for edge cases like someone being OOO but I'm trying to get as close to the ask as possible without having engineers manually filling in their time.

[Trudy Claspill]

More edge cases:

What if the Assignee is changed between the time the issues is moved to In Progress and then to Done?

What if the issue moves from In Progress to To Do/Open?

What if the child issue is removed from the Epic?

What if the child issue  is moved to another Epic?

What if an existing issue that previously was not the child of any Epic is added to an Epic?

Using only native Jira functionality there is no simple method to get the information you seek. It is going to take writing custom code and/or automation rules and more custom fields.

Example:

You could have a scheduled Automation rule that runs once a day and selects in the trigger all the Epics of interest.

Then for each Epic get the list of all child issues that are In Progress and Assignee is not Unassigned.

Iterate over the unique Assignees in that result set.

For each unique Assignee increment a counter for that Assignee in the parent Epic, where that counter ends up tallying the number of days each Assignee had 1 (or more) child issues of that Epic in the In Progress status.

Containing in the Epic a number field for each possible child story assignee is probably not practical. But trying to update, for instance, a text field that includes all the Assignees and their tallies would be more complicated.

Extracting the data from the Epic once you have it is another challenge depending on how you store the data in the Epic. Also formatting that data for presentation may impact the decision you make about how to create and store the data.

There might be third party apps that provide functionality (such as dynamic calculated fields) that might enable you to come up with a more dynamic method to look at the collection of child issues and calculate on the fly who each assignee has been and how many days the issues were in progress while assigned to each person. Or you could look at reporting apps that enable you to pull data from Jira and then manipulate it in different ways to calculate the information you seek.

[Birkan Yildiz _OBSS_]

Hey @mborinstein 

Calculating the total time each engineer contributes to an epic is a powerful metric, but it's not something you can get with native Jira reports.

This is a perfect use case for a Marketplace app. Full disclosure, I'm on the team that makes Timepiece - Time in Status for Jira, and it can create this exact report for you.

Here’s how you would do it:

You'd start with our Assignee Duration report.

Then, you'd use the Sum option to add up all the time an engineer spent across all their tickets.

The key step is to Group the report by 'Parent Key'. This rolls up all the data for the child issues into a single row for each epic.

The result is a clean table, just like this, showing each epic and the total time each engineer contributed to it:

You can also configure the report to only count the time between specific statuses, like 'In Progress' and 'Done', to match your exact definition of 'work time'.

This gives you the "total effort" (the 8 days from your example), which is incredibly valuable for understanding workload and each engineer's contribution to the epic. Besides, if there are 8 issues under an epic and you can see their total, you can also view a separate report for each of those 8 issues using the Drill Down feature.

You can check Timepiece on the Atlassian Marketplace. Hope this helps you get the data you need!

[mborinstein]

Thank you for this! Is there an option where it would count 5 days instead of 8 days in my example? If I wanted to know how many days in October did this particular engineer work on any tickets in this epic without double counting if there was overlap between two tickets? 

So if they worked on two tickets during October 13th - October 17th it would only count as 5 days spent?

[Birkan Yildiz _OBSS_]

To avoid double-counting or data overlaps, use the AVERAGE function instead of SUM. This will show you the average time an Assignee dedicates to an EPIC each month. For more detailed information, book a demo with us, and we'll work through your specific use cases during the session. 

[Rahul_RVS]

Hi @mborinstein 

If you are open to try out a mktplace solution for this need, I can suggest 

Issue Hierarchy 

The app allows you to view your Epic Hierarchy in a tree view. The app also has a feature to view time in status in the tree view with the ability to group the data by assignee. You can export this data to a csv file and slice & dice the same. Hope this will help to meet your requirement. 

Disclaimer : I am one of the app team member