Best Project Template to use for non-software related issue tracking with kanban board

[Todd Brake]

We've had Jira for several years.  It was used for a while and fell out of favor due to changes in personnel.  Small company, very little IT support.

I'm mechanical engineering manager.  We had Jira set up as a simple issue tracker.

Recently, our outsourced software group has begun to use it integrated with bitbucket and teams.

I'm attempting to resurrect it for use in our small mechanical teams, purely as a "change request" system where engineers, field service, or production staff can use a smart phone to report issues and snap photos of issues, that we can use to prioritize and assign the issues, track, and use Kanban board to present progress.

Seems easy enough....

I have two test projects.  One is a classic software "kanban" project, and one is a classic business "task tracking" project.

A colleague walked me thru the kanban project, and in general I like it, but would like to eliminate the sort of software specific parts of the issue window.  Seems like the business task tracking project will do this.

my first hurdle is I try to create an issue and I get this error "the default assignee does not have assignable permission"

My user is a site admin, but also belongs to groups "administrators, jira-users, site-admins, users" as far as I can tell.  What's the deal here?

Any tips on how I can create specific issue types for this business task project?  I'm looking for something like the software projects "bug, epic, etc" but maybe with names that will make more sense to the intended audience.

Thanks,

Todd Brake

[Michael Andolfatto]

Hi @Todd Brake , welcome to the Community!

Your first issue would be due to the project's permission scheme- administration groups usually assign the functionality across projects you would expect (when the projects are configured correctly) but each project can still restrict the permission scheme that applies to it.

In this instance, the default assignee does not have the Assignable User permission. You can read more about project permissions here and I would make sure that you read up on the implications of making changes to shared configurations before modifying anything in Jira.

For the issue types, Epics, Stories, etc. are common for Jira Software projects as they are Agile terms. For a Jira Core/Business project with a simple board, it's common to use the Task and Sub-task issue types. You are able to configure custom types as well, but the names will likely depend on what is relevant to your business.

[Todd Brake]

Michael, thanks much for your reply.  I'm poking around in there now, and I understand that at this moment my user can't be the default assignee till I make some changes....  Many of these will be assigned to me, but we won't really have a default user - or, if that's necessary it will be me, and then I'll reassign to other team members.

Let me poke around some and I'll get back to the thread thanks again!

TB

[Michael Andolfatto]

No problem Todd. The default assignee can be turned off by accessing Project Settings > Details > Default Assignee and setting the value to be Unassigned. You may also be interested in Components, which allow for automatically assigning tickets based on the Component Lead.

[Todd Brake]

I'm sorta getting somewhere....  but still haven't decided whether to use a software or business type template.  Basically fooling around with it.

I found that I had to add myself to the default "user" category to make that problem go away in my Business project.  I tried to do what you mentioned, but for some reason I could not change the default assignee value - it was like it was hardcoded.  I think I came across a global setting that was set to "NO" something related to this, but I was afraid to change it and screw it up.  Adding myself to the user category allowed me to start creating issues.

This was not a problem using a software kanban project.

So I think I figured out how to create different issue types and customize the issue dialog to remove the stuff I don't want.  Definitely getting there

Thanks again for your help!

[Todd Brake]

My biggest problem I'm having, is following where the configuration changes are made....  Because the whole of JIRA is a pretty vanilla web page, not an typical GUI per se, I can't figure out where I'm at.  I feel like I'm walking around in a city with no street signs....

Basically I want to create new issue scheme and new issue screen, with my own custom issues.

I figured out how to change the name of the columns in the Kanban board, so that's looking good.

I guess I'm concerned with accidentally making changes to schemes that could affect our software projects, so I'm looking to create new or copy a scheme rather than changing any that are default.

Can you tell me, by default when I create a project, does it also automatically create a copy of the schemes?  Or by default, are they still connected to other projects?

In what order should I create these new items?

Tahnks!

TB

[Michael Andolfatto]

Hi Todd, your questions touch on a lot of intertwined topics so I'll try to cover them in a high-level summary.

Jira Cloud has a few different project options. First, they come in one of two types- Classic or Next-Gen.

Classic projects utilize a shared pool of configurations (that only Jira Administrators+ can create or modify) From this pool, Jira Admins place configurations in Schemes (containers) and each Classic project can have a single configuration type scheme hooked up to it. (Project A has room for precisely one Workflow Scheme and one Issue Type Scheme, etc.) Your Project Administrator can choose which schemes/containers to connect to their projects. Classic projects can be created via the standard fashion, where most of their default schemes are unique and created just for them, or can be created via shared configuration (where they share schemes with a project used as a blueprint)

Next-Gen projects on the other hand, don't utilize that pool of shared configurations. They give more power to the Project Administrator by allowing them to create their configurations which only live locally within the project. They don't exist outside of it.

After selecting one or the other, you then have your different flavours (Service Desk, Software, Business)

If you've chosen a classic project- typically the schemes associated to it will not be shared with other projects. But you can verify this in the project's settings. Navigate to the notification scheme hooked up to your project for example, and underneath the name you may see a flag that says Shared with X projects. If they are not shared with anyone else you don't need to worry about the changes you make to the scheme (Remember that the base configurations are still shared globally, changing an Issue Type's name for example will reflect it everywhere)

When creating new projects, my order of operations is typically: Issue types > Screens + Fields > Workflows > Any other configurations as needed.

[George Mihailoff]

+1 for next-gen, a great option for simple use cases.

[Todd Brake]

Let me make a sample project and see how that works.  That might be the best way for us to move forward with our eng projects.

I have site admin access (since we do not employ any staff IT, only consulting) but I have regular job also, only so much time to spend on this.  I could use it the way it is, but like I said would like to have the issue types more reflective of our business.

Appreciate the help guys, might be a few days before I can get back to this.

TB