Custom Field via Automation for Count of Unique Assignees on Child Issues in an Epic

[mborinstein]

I would like to know how many unique engineers have worked on all issues within an epic. Is there a way to use Jira automation to build a custom field on an epic that captures the # of unique assignees that have worked on any child issue of that epic?

[Petru Simion _Simitech Ltd__]

Hi @mborinstein ,

You can write your own custom field, however it will only display the value on each issue. 

If you are open to apps you can use Issue History Dashboard for Jira (Work Item History)  app released by our company.

You can filter out by project and other filter criteria. If you want to display by use you can use the Assignee field. Otherwise you can search for all data and order the result by field Assignee.

You can export the search result in CSV format for further processing and data drill down using Excel or the tool of your choice.

Regards, 

Petru

[Deniz Oğuz - Starware]

Hi,

If you are open to using apps from the marketplace, you can use our "Calculated Custom Field".  Although it uses the Jira Expression for calculation, it is simpler than creating an automation. I have prepared a sample script to show how the field can be used. You can also use the expression in automation if you need to.

issue.childIssues.map(issue=>issue.assignee).filter(assignee=>assignee != null).reduce((all, current) => 
all.set(current.accountId, current), new Map()
). entries().length

PS: I work for the vendor of this app.

[Ivan Manolov - JXL]

Hi @mborinstein ,

I am no automation expert but I trust that @Bill Sheboy and @Marc -Devoteam- answers make good sense.

If you’re open to solutions from the Atlassian Marketplace, your use case would also be easy to solve using the app that my team and I a working on: JXL for Jira.

JXL is a full-fledged spreadsheet/table view for your Jira data that allows viewing, inline-editing, copy-pasting, sorting, and filtering by all your work items' fields, much like you’d do in e.g. Excel, Google Sheets, Smartsheet, or Airtable. It also comes with a long list of further features, including support for configurable issue hierarchies and sum-ups.

With these, you can build a view like e.g. this in just a couple of clicks: 

You could see the work items grouped by epic and on expand, the unique assignees count is displayed as sum-up. No automation or whatsoever, this just works.

I should also add that JXL can do much more than the above: From support for grouping, to conditional formatting, or inline bulk editing via copy/paste.

Any questions just let me know,

Best,

Ivan

[mborinstein]

Hi Ivan,

Does JXL have the ability to track time spent per engineer/ticket as well? I'm exploring some of the other apps like Timepiece or Time in Status. Ideally, I'm also looking for the # of days per month that an engineer is spending on tickets within an epic. The tricky part is that I don't want it to just sum up all the days that each ticket is worked on. I would like to know if an engineer has had tickets In Progress for 5 days in October.

[Ivan Manolov - JXL]

Hey @mborinstein,

Thanks for the question. JXL does show tracking data (Original estimate, Time spent, Remaining estimate...) in columns but it's not configurable per work log author yet. This is a common request and it is a planned feature. 

You could watch for the "Configurable time tracking columns" item in https://jxl.app/docs/roadmap/  

[Bill Sheboy]

Hi @mborinstein 

If you wanted to measure this value from this point forward, you could:

• add a multiple-select user custom field to the Epic
• create rule #1 where when a child work item is assigned, update the parent Epic to add a selection for that assigned user; this could be further restricted by engineer users with groups, lookup tables, etc.
• later when the count is needed, use rule #2 which counts the selections in the custom field

To measure this for existing Epics, the approach described by @Marc -Devoteam- to check the changelog history could be used...or investigate marketplace apps which can perform this type of analysis.

Hi @Marc -Devoteam- -- In my experience, when teams have individuals (rather than pairs / mobs / teams) work on work items, counting this measure may help manage several of the Lean wastes: delay, task switching, motion, over processing, and management activity. (And perhaps also the others too: inventory, defects, and over production.)

Kind regards,
Bill

[Marc -Devoteam-]

Hi, @mborinstein 

Theoretically probably.

You would first need to get all issues and then branch over all the issues and within the branch create a web request to get each of the issues change logs and find all assignee changes.

Then would would need to store those in a variable, then remove all duplicates.

It will be messy and probably will fail at times.

My real question is why, what would this KPI bring you?