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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.