How to structure Jira projects

[Erik X]

Sorry for how long this is...

Where I work, we use Jira, but I don't feel we're using it to good benefit. In fact, I think we're using it quite wrong. However, I can't really figure out a better way to do things, so I'm hoping I can get some help on how we should go about structuring our projects.

First, what I mean by structure our projects is how we define our overall set of projects, when we create projects, etc... I can't imagine our situation is all that unique but so far i've been unable to find any insight.

It seems most people create projects based around a product. You create versions and components, and you assign issues to them. You can then assign issues to sprints or one-off them or whatever. That's not really the way we use it.

First, a little background. We do not have a "product" per se. We have an enterprise system. It's a whole bunch of applications that work together. You could call these components, but the problem is that many of them are components of multiple other components. For instance, we might have a web service that is used by several different top level applications.

When we do "projects", they tend to be oriented around features... For instance, this is the Blah Foo Release of the website, or the Blargh Bar release of our support desktop clients. To make things more complex, due to our "release" system we often roll security and bug fixes that are unrelated to the features into a feature release, because they have to be deployed in the same deployment window.

So in reality, while the projects start out as feature releases, they end up as Release window releases (ie whatever is ready to go during that window gets deployed).

So what we do is create projects based on the feature name. We don't really take much advantage of the component or version fields, unless a project spans multiple phases. When an issue is bumped to another release, it gets moved to that project which causes it to be renamed/numbered. This can lead to the person working on that feature not having access to the issue anymore since it was moved to a project they don't have access to (he wasn't on that project, so he wasn't included in it), so now we have to go through a user access process to give that developer access to the issue he's already been working on.

This all just seems like we're fighting the tool. Can anyone suggest a better way to structure things? Bear in mind that we still need to track issues by project as well, and unfortunately we're not "agile" at this time so using sprints is not going to work. We also want to give developers access to the issues for their project, not just issues assigned to them or issues assigned to the application/component.

[Andrew Wolpers [BlackPearl PDM]]

I think just using fields a bit more might really help you guys as far as querying and organization. Instead of creating a new project for each Feature or Release, have an over-arching project for your Product or System.

So, if you were to say be developing something like "Word" I would do this:
Project: Word (WRD)
Issuetypes: Bug, Feature, Task, Subtask
Fields:
- Summary
- Target Date
- FEATURE FIELD (Can be done through a select list, or using Components if they're needed to quickly roll out or add)

Without knowing how large your organization is/how easy it is to get to your JIRA Admin and make changes I can't say if a field that needs to be updated once a month is a good idea or not, but I would suggest having the features be called out some other way aside from a project for each. That just gets full and eventually difficult to use and keep things straight with.

If you guys are trying to keep that model, maybe consider "Archiving" projects and creating a category and role to do so. That way people in an Archiving group will be able to go in and check things if necessary, but it won't plague everyone on the project list/you'll be able to ignore the category if you're the average joe.

[Erik X]

Thanks, that falls in line with what i was thinking.. but there are some problems. First, it basically means giving everyone access to the global project.. I don't see how you could assign project leads to be admins of just their tasks, etc... How do you make a person a project lead on one project, but not in another?

[Andrew Wolpers [BlackPearl PDM]]

You mean be a "lead" (which I'm assuming is an arbitrary role you're using in the permission scheme) or have multiple in the same project? Say your "Word" project had a "Color" feature, "Lines" feature, etc. Are you saying the lead of the feature type? Say Tommy was the "Color" feature lead or PM, etc.

If I'm understanding that correctly, it may be more beneficial to build that into the Workflow using Validators and/or Post Functions if you're worried about people picking up extra work.

The easier route would be to build dashboards for each team, possibly building filters or queries from the proposed new fields. Then just encourage anything that would enter the dashboard to be their workflow.

[Erik X]

Jira allows you to assign a "Project Lead" to a project. There would be no such functionality in the methods you are describing. Everyone on our teams is a project lead in one project or another, but we don't want them to be project leads for every project.

Project leads do project administration, which you don't want to give the normal users rights to.

So, if we're going to develop project with a given set of features, named "Foo", and this project also contains a set of bug fixes unrelated to the features, and it contains a number of features that get "added" to the project over time (they may have been part of a previous project that got bumped to this project, for instance). How exactly do I let my "project lead" manage all these issues without giving everyone rights to it?

[Andrew Wolpers [BlackPearl PDM]]

I see what you're saying. The only real way to lock that down entirely would be what you're already doing with project-speciffic-projects.

Even if you were to give someone the "Administrator" permissions (in the Permissions Scheme) then you would still run into that issue. You could give them Admin rights (By using the out-of-the-box Administrator Role) and provide additional training and expectations so they didn't touch one another's issues/projects and just build that separation mentaility through a combination of training and dashboards.