Advice for organizing projects

[Paul Cleary]

I work for a company with a Single web portal with multiple "modules" within portal.

Currently, I am trying to keep everything in a single JIRA project, and using "components" as the modules.

We can use the same workflow / statuses / etc for all issues, so I figured it made sense to use one project for everything.

However, the backlog for this single project is getting pretty big and unwieldy.

I was looking for advice on when to break a project out to multiple projects. Is it when workflows deviate, permissions, etc.?

[Justin Alex Paramanandan]

I agree with what @Randall and @Timothy mentioned above; allow me to eloaborate on what I'm planning to come up with for our current JIRA instance.

1. First off, the project outline. Look into your current project and components. Is it possible to break up these components accordingly to a generic category. For example, you may have these components in your project:
   • Product A Development
   • Product B Development
   • Product A Testing
   • Product B Testing
2. Based on the above components, the generic categories can be Development and Testing.
3. Create project roles to make the handling of schemes easier (just the roles; don't add users into them).
4. Setup your schemes (permissions, notifications, issue types, workflow etc) to cater for the generic categories you have. Try to use a generic naming convention for the schemes:
   • Development Permission Scheme, Testing Permission Scheme
   • Development Notification Scheme, Testing Notification Scheme
   • etc
5. Now that the schemes are set up as such, you can then proceed to fine-tune the rest for them (try to use project roles often, as it would be easier to adjust the user settings later on); such as:
   • Screens: which projects would have certain fields; are they all required? optional?
   • Workflows: what transitions are needed? any new statuses? new steps? are these settings for all issue types or just some?
   • Permissions: are users allowed to view all projects; or only certain ones?
   • Notifications: should all users get notifications?
   • etc
6. Associate the set up you've done in steps 4 and 5 to their respective projects categories. In this case, Product A Development and Product B Development would have all the schemes with the "Development" keyword in their names; the same goes for the Testing projects.
7. Since you've created the roles in step 2, associate the users and groups in all the created projects. If you set up your schemes (screens, permissions, workflows etc) to specific roles, they would take effect almost immediately.

That's the above setup that I come up with for my current company's JIRA. The way it is done above is quite generic which allows feasibility and easier management for future enhancements. Plus, the changes you made for a category's scheme would be shared across all the project under that category.

Of course, you can make schemes which are specific to a project's name; but remember the performance overhead and the management of the projects would be a tad tedious.

[Randall Robertson]

Your situation certainly sounds like a good candidate for multiple projects. Timothy Chin mentioned that workflows, permissions, etc. are packaged in schemes that can be applied across multiple projects. You can certainly break your modules out to different projects and just reuse the same workflow scheme, permission scheme, notification scheme, etc for all of the projects without creating much additional work. If you find that workflows, permissions etc do begin to deviate, you can always copy the base schemes and customize them accordingly, too.

Another thing to consider is how you will be searching JIRA for these issues. Do you need to set up gadgets or filters that show issues across multiple modules? If so, then your queries may have to include project in () instead of component in (). Not a whole lot different either way, but maybe .

One other thought: how many levels of organization do you want? Would the components field be useful when dealing with a single module? If so, separate projects might be better. If not, then splitting them into separate projects might be a little bit of unnecessary overhead - unless reducing the backlog size is worth it. It wouldn't be much additional overhead, though, as noted earlier.

[Randall Robertson]

Additionally, breaking out to separate projects means a difference in the issue keys, which might make finding items in a specific module easier. Again, not a big difference, but some.

e.g. Quick Search for My Open XYZ (returns all open issues assigned to the current user in project XYZ) is a little easier than My Open ABC c:XYZ (returns all open issues assigned to the current user in project ABC that have component XYZ).

[Timothy]

Backlogs are managed with multiple quick filters.

Is it when workflows deviate, permissions, etc.?

Projects should deviate when issues created do not match the project context. For example, you don't create a leave application in a software development project. Remember that schemes (and such) can be used for multiple project.

[Paul Cleary]

Not sure I follow "you don't create a leave application in a software development project".

I do use quick filters, they are really great.

With the Rapid Boards, I certainly pull from multiple projects. However, versions then become a bit of a pain to manage