0

I am to set up Jira in my organization and there arise some questions, for which I could not yet come to a, for me convincing, decision... may you give me your opinion, what the best configuration would be? (I will be talking here about projects but it might be found out, that should later be boards or whatever)

  • I have requested my org the creation of a Jira account for my department, and as seen from the settings, I got created a Board associated to me as an admin
  • We are a team of 15 people in the department
  • We want to start setting 10 different projects, some might be related to the other ones but still keep an individual sense, thus, each should have its own Backlog
  • The scheme of the projects should all be the same (notifications, workflow, issue types...). Ideally, if changing something lately in the scheme, all projects should actualize to this automatically
  • We will be all teammates allowed to work on all projects within the department, always, no restrictions
  • We want all to be able to check for the statistics etc. related to any project in the most easiest way
  • Users want to have on their board (screen) all projects and tasks, in the order planned for them to be performed, don't matter if they belong to different projects. Desired view would not be a flatt Kanban but issues being classified by Project > Epic > Sprint

The ideas I came up with are:

(1) Me --> Board --> 1 JiraProject --> n Epics (each = OurProject)

Having just one project (namely, the name of my department) and then create one Epic for each "real" project we want to handle. Then, to each Epic create the Issues related to each of our real projects. The problem with this is, that we would need a second level of Epics to suborder into each of the main Epics (representing our real projects) so that we can group their issues into logical parts of the project. This second level of Epics seems to me not to be possible. Additionally, this approach will just provide us with one Backlog common for all our projects (here provided as Epics).

(2) Me --> Board --> n JiraProjects (= OurProjects) --> each JiraProject

This seems to me to be the best approach, but has the inconvenience, that when a person has to work on several projects he has not the insight of the order of the tasks he has to perform, nor if any of these collide in time with any other of any project.

Rubén
  • 34,714
  • 9
  • 70
  • 166
Paul Efford
  • 261
  • 4
  • 12

1 Answers1

0

I ended up creating a single Project with a single Board.

In Project Settings (left side panel, bottom):

  • I enabled Components to appear on the left side panel
  • I set Issues to show the field "Component" when they are created

The Jira logical classification will be now like this:

  • PROJECT is my department

  • BOARD is the common view all users will share

  • VERSIONS are Versions

  • EPICS are my different Projects

  • COMPONENTS are now a kind of Epics for my projects, but with the disadvantage that:

    a) they are all shown in a separately view, not as a side panel similar to VERSIONS and EPICS

    b) they are all listed straight forward, which requires to give an identifier at the beginning of their name to differentiate to which Project they belong to

  • USERS: all Users will manage to see the main Project (which is my Department) and inside of it, all the Epics (which are my Projects). This was initially my requirement, so it is ok.

I wish Jira was a bit more flexible on letting us creating some additional group categories similar to VERSIONS and EPICS, so that we could get and extra group layer. The use of Components here is not really very useful, but also confusing and not intuitive, but is the only option available at the time of this post to extra group somehow my Issues.

Problem:

  • Customers that become access granted, can access and see all or projects, what is naturally not good!
Paul Efford
  • 261
  • 4
  • 12