Help reporting on my project achievements.

Hi I run a program of 40~ projects where there is a business engagement with an end customer.  I’ve have the same kanban board for all my projects and same configs.  

Out of these projects, different levels of work can be achieved.  Some just go as far as business engagement and never progress.  Some go from business engagement to a workshop. Others have business engagement, a workshop, and Proof of Concept.

At the moment there are numerous issues on my board like tasks, epics, and bugs etc.  The above items are just tracked as Epics on my board at present, meaning that there would be subordinate tasks mapping to them.
I would like to get some reporting on my program, so I can report on how many projects have completed 'business engagement’, ‘workshop’, and ‘Proof of Concept’.

In order to do this would I need to create a new issue type, as per the 3 items above, and then right some JQL to, show which of the following issue types, have the status of Done, order by project?
I’d prefer not to have to create 3 new issue types.  Is there any other way?

Thanks in advance :)

2 answers

1 accepted

1 vote
Accepted answer

As a rule of thumb, you should only create a new issue type when that's the only technical way of applying a requirement, such as when the different kind of tasks within the very same project require:

  • completely different workflows,
  • to have a different selection of required and/or hidden fields,
  • distinct set of fields to be shown on create, edit and/or view screens,

and so on.

That said, if none of those requirements are in place, the correct approach would be:

  1. create a new single select custom field (if it doesn't already exist), named ie: 'Task Type', with those 3 values. If there's already an existing appropriate field for that purpose (or if you need to apply the same logic to other projects) then you should just create a new context for that custom field & project combination, so that you can display a different set of options for that project, while reusing the existing custom field.
  2. make the field required for all issues in the project by editing the appropriate project's field configuration.
  3. add the field to all screens in use by your project.

Steps 2 and 3 should take into account that the modified schemes are not shared by any other projects. Otherwise, you may proceed to copy those schemes first, apply the changes to the copies and finally set the modified schemes to your project.

Hope it helps.

Hi Stu,

Have you thought about using labels instead of new issue type? It should help in your case.


Lime Trees Support Team

Labels are a cool way for informally classifying issues, but adopting labels as a way for distinguishing types of issues here would negatively impact:

  • reporting
  • browse-ability of eligible values
  • and require-ability (bypassed by typing anything)

So I'd discard this approach, given the description of this use case.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,088 views 4 9
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you