Estimation issue type?

[Tony]

Does anyone have recommendation on creating a new Jira issue type to support a professional services SOW estimation activity?

Currently we use an EPIC to represent a large chunk of work billable to a client. We are now considering a shift to use EPIC type to represent a portion of the work order and would like to be able to group multiple EPICs together so we can clearly see which are associated with the same work order. From a backlog grooming standpoint, having multiple EPICs in flight simultaneously may be cumbersome to manage/track. 

Soliciting any feedback to help put us on a track for success managing multiple client initiatives using one Jira project.

Decisions

• We use one Jira Project to manage all work for a client
• We have two stream of working being introduced to each client project 1) production support issues 2) planned work
• We use Epic to represent a single billable effort.
• we use stories associated with each EPIC to represent portions of the overall deliverable.

Opportunities

• we are not using components
• we are not using releases; are considering using this going forward to reflect a single billable effort to support more autonomous reporting on work order progress and resource allocation/time spent vs estimated.
• We have considered using custom field for issue(s) to tie multiple issues together.

[Troy Spetz]

We use JIRA 7.10 server version.

A few comments:

1. It seems to me that an existing 'Chore' issue type would be sufficient for your estimation work. (We use Chores when the result of the work performed is not a code change. One exception to this 'rule' is that Chores are also used to write scripts, e.g. for the software release installation kit).

2. JIRA does not support Epics within Epics. At best, you can link two Epics together with the 'is related to' link. JIRA Portfolio (which we do not use) provides one additional higher level grouping: Initiative. I believe you can group multiple Epics under a single Initiative.

3. Using the JIRA native Components and FixVersion fields will give you some added value, as they are used by other functions within JIRA.

4. Custom metadata fields may be the only way for you to link issues, if none of the existing, native fields meet your needs.