Help reporting on my project achievements.

[Stu]

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 :)

[Ignacio Pulgar · Accepted solution]

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.

[Lime Trees]

Hi Stu,

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

Regards,

Lime Trees Support Team

[Ignacio Pulgar]

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.