Initial Set-Up of Jira

[travis]

Hello,

We are looking at moving from Asana to Jira for our project and task management.  We will have 3 - 4 departments that could use Jira although the main reason for switching would be for our Engineering team to have additional clarity in the actual projects or tasks. Equally important is better reporting to see the work that is being done, tasks and bugs coming in, and better visibility for the entire organization of what’s being worked on, what’s been completed, and what’s on the roadmap.  

I think I’d like to keep the engineering team tasks and “projects” in a single Jira project and separate by versions and components although I’m not sure that is the best solution.  The engineering team could be broken into two teams, one for new products and features and another into implementations and app extensions although they are both cross-functional and team members do work in both areas.

The second thing I’m having a hard time in determining is how best to have our on-boarding team (separate from the engineering team) manage in Jira.  Right now, a new project is created in Asana for each new customer with the list of assigned tasks to get them on-boarded. I don’t know if that is the best solution to have a new "Jira Project" created for each customer or separate those differently.  There can be and usually are engineering tasks that would get assigned from the On-Boarding project as well. I want to make sure those get tracked as part of the work the engineering team is completing but not sure of the best way to move those between departments or projects and still keep clarity and ease of reporting intact.

I’d love any insight into some ideas on how I might accomplish this in Jira.

[Rachel Wright · Accepted solution]

Hi @travis, nice to see you in here.  :)

I would definitely recommend keeping the Engineering department in one project.  In fact, you only really ever need an additional project when you need a different Permission strategy, Notification strategy, or can't agree on a common naming convention for Components and Versions.  You can distinguish between new products, features, and other work with Issue Types, a custom field, labels, or even Components (although, I'd use your Components for routing (auto assigning) work based on whatever criteria you use in real life.) 

Too many Jira projects for no real reason just means more administrative and maintenance work for you in the long run.

For your second question:  Does your customer log into your Jira instance?  If so, you'd probably want a different project so customer A can't see the tasks related to customer B.  If not, there's no reason to have one project per customer.  Instead, use one Epic to represent each customer and link any issues related to that customer using an "Epic Link".  Or, use a Component, custom field, or label.  That way, you can report on and segment which issues in the project are for which customer.  Here's what the query would look like with the two different methods.

One project per customer:

project = customer-name and status !=closed

VS

One project for all customers:

"Epic Name" = customer-name and status !=closed

The query is not all that different, right?

Hope this helps!

Rachel Wright
Author, Jira Strategy Admin Workbook

[travis]

Thanks @Rachel Wright  for the quick response.  To answer your question about the on-boarding team, no, customers will not have access so it sounds like one project with Epics as the separator would be best.  

I'm still a little unclear as to how the assignment of a task from the On-Boarding Project to the Engineering Project will work though. 

1. Will On-Boarding be able to assign a task from the on-boarding project to the Engineering Project to complete or will our devs just work out of the On_Boarding project?

2. If they can move the task between projects, are there any commonalities between those two projects I need to be aware of when setting them up?  

3. Last, if that task can be moved to the engineering project, when it completes, what would be the flow for the on-boarding team to know or see the status of that task.

Thanks again for the help!