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.