How should my Jira projects be organized?
If I had to pick one question that I get the most from new Jira administrators, I think it would be:
How should my Jira projects be organized?
Like many things in Jira, there are lots of options available. Sadly, I’ve never found a reliable crystal ball or sorting hat that can guarantee what will work best for any given situation. What I can do is share what you should consider to help you make the best decision for your teams.
First things first though:
Before we start Marie Kondo-ing our work into Jira projects that bring us joy, let’s make sure we first know the answer to this very important question:
What is a Jira project anyway?
Typically, a project can be defined as a collection of tasks that need to be completed to achieve a certain outcome. In Jira, a project can be thought of as a container used to organize and track those tasks, or issues, across the entire team (or project). [from: Jira projects overview]
That project container has assigned workflows, permissions, and schemes that apply to all the issues contained within it.
What about boards then?
We also need to think about Jira boards, because projects aren’t the only way to view Jira issues. Jira boards are a collection of issues determined via a Jira filter. The columns on the board map to the statuses in your workflow(s). Company-managed Jira projects can have multiple boards.
As an example, let’s say I'm a designer, and I provide design work for several development teams. Each dev team has its own Jira project. Does that mean I need to go into multiple Jira projects to see all my work?
Nope! 🙅♀️
I can create a Jira filter to show all work assigned to me across all my projects and then create a board from that filter. Voilà, a single view of everything I need to focus on!
The flexibility of accessing issues via the project or via boards helps Jira to scale to each user’s needs—via a board, you can see just some of a project’s issues, all issues, or issues from multiple projects. Hopefully, that takes some of the stress out of getting your projects exactly right!
|
💡 Pro Tip Did you know that you can view all of your Jira boards in one spot? Click in the Search bar in the upper right corner > Select Go to all > Boards. See below: |
Back to the original question
Now, back to the original question – How should my Jira projects be organized?
Jira projects are frequently organized by:
**Listed in no particular order… 🥁
- Team or business unit
- Product or Product Line
- Platform (desktop, mobile, front-end vs back-end, etc.)
Got it? Great, I’m out of here! 🏃♀️➡️
…
Kidding. I learn best by example, so let’s walk through one. 👇
Let’s work through an example
Acme has the following products:
- Acme Online shopping website - supports Chrome, Safari, and Edge
- Acme Mobile shopping app - supports iOS and Android
- Acme AI Shopping Search Engine - supports Chrome, Safari, iOS, & Android
Acme’s development org consists of three development teams:
- Two teams dedicated to Acme shopping (it’s their flagship product!)
- One for the new Acme AI product
The AI functionality is completely separate from shopping, but the shopping teams have many dependencies between the browser and mobile apps. Some mobile app developers work on both shopping and AI.
Given the above, what would the Jira project structures look like for each approach? 🤔
Organized by team
This is probably the most common way of organizing Jira projects. Good for:
✅ Teams that don’t have a large number of dependencies with other teams
✅ Teams where team members are relatively stable, as opposed to environments where team members may change frequently
|
What would Acme’s Jira projects look like if organized by team or BU? Three Jira projects, by team:
Mobile stories are in the same Jira projects as browser stories. They could be differentiated by Jira components or a custom field called Platform, which allows multi-select for all applicable options. When needed, boards could show only mobile or only browser stories. Jira Plans (formerly Advanced Roadmaps) can show dependencies between the two shopping projects, and the dev teams can also use the Blocks / Is Blocked By relationship to show dependencies between dev teams 1 and 2 for the shopping app. |
Organized by product
While not as common, organizing by product can be useful in the right circumstances. Good for:
✅ Multiple teams working on the same product or product line
✅ Teams with frequent cross-team dependencies
This puts all the work related to the product in one place, and individual teams can use boards to view just their portion or view everything when more visibility is required.
|
What would Acme’s Jira projects look like if organized by product or product line? Two Jira projects, by product:
Mobile stories here are in the same Jira projects as browser stories, as in the previous example. Again, the mobile vs desktop work could be split out by boards, as well as splitting out the work for dev team 1 and dev team 2. Dependencies for the Shopping product are now all within the same Jira project, making dependency management easier. |
Organized by platform
This is also not as common, but you may find it's the right fit for you! Good for:
✅ Products where there are significant differences between platforms
✅ Multiple teams working on the same platform
|
What would Acme’s Jira projects look like if organized by platform? Two Jira projects, by platform:
Here the mobile versus desktop stories are organized by Jira project, there are now shopping and AI stories mixed in together. A custom field could be used to indicate what app a story applies to (Shopping or AI) and boards could display different views. Dependencies for the shopping apps across desktop and mobile are now in separate projects but can still be linked via Blocks / Is blocked by links. A custom board based on the above custom field could allow views of just shopping or just AI across desktop and mobile projects. |
So, which option is the best one?
There are pros and cons to all of the above options! So, how should we decide?
Ultimately, it's up to you and your teams! Here are the key things to consider:
- Team productivity - For development teams, having all their work in a single project makes visibility and reporting easier, plus no backlog black holes!
- Shared workflows, permissions, and schemes - Since a Jira project is really a container for issues with shared settings; it makes sense to group issues based on the workflow, permissions and visibility of that work.
- Dependencies - If you have work that has a lot of dependencies to manage and track, grouping that work together helps with dependency management.
Many thanks to:
I read several posts on this topic from the Atlassian Community while writing this, so I have to thank those who have shared their thoughts previously:
- John Funk - Should I create projects per team or per product? My small team works on every product
- Josh Costella - How are your Jira projects organized?
- Jack Brickey - What do you use Jira Projects for? Teams, Projects, Products, Programs........???
- Mark Segall JIRA Project Vs Teams - Best Practices
- Mary from Planyway & Matt Parks - Question around whether multiple Jira Projects or 1 Jira Project is better for a team's work
Let’s keep this conversation going - what did I miss? How do you like to organize your Jira projects? Let me know in the comments!
Was this helpful?
Thanks!
Peggy Graham
1 comment