Best setup for one team, multiple projects both small and large

Question

Hello! I'm new to Jira and trying to find the best solution for setup for my team.

I work with a small team, but we receive multiple projects. These projects can range anywhere from a few weeks to a few months and sometimes longer.  The projects can be as small as making a report or as large as predictive analytics.

Does it make sense to create multiple projects for each individual project? I want to kind of 'group' all these multiple projects under our team, but so each project can have it's own space, but still be part of the group? If that makes sense. And each project would follow the same guidelines from start to finish.

The rest of the company also uses Jira, so I want a way to group our team's projects without making 20+ 'project' boards for these multiple projects and spamming our company's projects page even for the smallest project.

Any suggestions would be appreciated! And sorry if I am using the Jira lingo wrong. :)

Thomas Robbs_0541h6 · Answer

In my experience, the answer lies in setting up the tool to serve the teams delivering on the work, and organizing the work in a way that serves reporting on business objectives.

It's worth mentioning that "agency work" is different that work tracked internally for a company working towards specific objectives, so you can replace "business objectives" with "client projects" if you like, but depending on their size, you may need to expand your work organization strategy.

On the team side, the best practice is one board per team.  With that, you should have one board that allows the team to manage their delivery on that work.

On the work organization side, Atlassian provides a few options.

1. Jira on it's own, at the lower pricing tiers, gives you Projects, Epics, Stories/Tasks.

At this level, you could consider just creating one Project, and organizing what you are calling a "project" by using Epics.  Your varied project length is akin to a software team producing features for a product - some take weeks, some take months, etc.

Alternatively, you could create multiple Jira Projects, each with their own Epics, Stories/Tasks.  Your Team's board would merely be configured to display work from all of the Jira Projects that have been created.  The overhead here is having to routinely update the configuration of your Team's board to add/remove projects at the beginning / end of their lifecycle, and take care with naming of Epics/Stories/Tasks so that it doesn't get confusing as to which project they came from (there are other mechanisms that can be used to help the Team differentiate between projects, but if this gets large, it can be somewhat messy for them)

2. At Jira's higher pricing tiers, you get the ability to add additional levels to the Issue hierarchy.

A simple example is adding a level above Epics, e.g. Initiative, or Strategic Objective.  In your case, your team may need the Epics-Story-SubTask hierarchy for their own organization of a project's work.  So you could create a Project issue type and make Epics children of it.

Further, at these pricing tiers, you also get access to Plans, or Advanced Roadmaps.  This is a much more enhanced version of what you may see on your Jira Project's sidebar called Roadmap or Timeline.  This may be very useful to you to manage reporting, planning, etc. You create Plans, which can be configured to draw from a number of Jira Projects, or Boards, or both.

Finally, I'd echo what Clark said in terms of thinking about the Reporting / Managing side of what you're trying to achieve.  Jira mainly has reporting by Project Version and Epic (there are other reports but they're more for managing the delivery of the work rather than graphing progress and projections towards "Done" which you may be more interested in).  But I would also look at Advanced Roadmaps to see if that is more of the reporting you're looking for - Gantt charts and such.

In closing, it's worth repeating again - with one team doing the actual work, whichever path you take, don't lose sight of how important it is that the choice you make needs to support them.  If you choose a path that is best for your reporting needs, you may find yourself overcomplicating things for your team, which slows them down and can lead them to devalue your choice and the tooling - sometimes, even the whole project management practice.

Side Note:  I took the time to write this out for two reasons.  First, it's something that I've been forced to experiment with inside of Jira over the past decade or so, and this problem space continues to evolve as Atlassian evolves the tooling I referenced.  Second, related to the last point, if I've missed something, or another option, I'm hoping someone more experienced than I can respond and add to / expand on the list of possible options.

Nicole Paul_pcvk18 · Answer

Thanks for the response, Clark.

I guess my biggest concern is not having multiple boards, because one would be just fine across multiple projects. My concern is creating multiple 'projects' even though some of those projects are quite small (may only span for 3-4 weeks) so would it really be necessary to create it's own 'project' for it?

Meanwhile, we have 2-3 projects now that have a timeframe of months, so those make sense to have their own 'project'. But also, since we work on multiple projects throughout the year (about 10-15) I didn't want to clutter our Jira space by adding 10-15 'projects'? Does that make sense? And does it make sense that for less intensive projects (maybe less than 3-4 months time scope) that may they should all be housed under one 'project' instead to avoid clutter?

Clark Everson · Answer

Hi @Nicole Paul

Welcome to the community!

can you share more about what you are looking for especially on the reporting side

the reason being is either approach can work it’s what’s nice about jira. But it honestly depends on a few factors:

first and foremost what type of reporting are you looking for not necessarily now but once the project is really rolling

who are involved and how do you plan on incorporating

how do you think this will scale

the reason for these is because one project with many boards can work very well as it’s easy to manage permissions

but let’s say you’re part of a enterprise and longer term you know you need to make easily digestible reports to scale later separating out work by project level and higher level work can help or via different teams can help

boards are actually fairly confusing, while boards live in projects boards aren’t actually a function of one project they are part of filters so one board could have many projects in it.

but there really is no correct answer to this however with more information there could be a better answer for your team specifically depending on longer term objectives

best,

clark