Per the question above, I'm curious on opinions about the best way to use projects, components, versions, releases, etc. when building a SaaS product. As you might expect, the product consists of a platform (that includes key capabilities like security, data integration, reporting, etc.) and a number of applications that sit on top of that platform. Should we do: * Project: Platform* Component: Security * Component: Data Integration * Etc. * Project: Application 1* Component: Component of App 1 * Etc. * Project: Application 2* Component: Component of App 2 * etc. Or is there a better way? We have Jira Software Standard right now, but we're evaluating Premium to get access to Advanced Roadmaps. We'll need that to do capacity planning, etc. I'm certain there's a lot of nuance, and we're just looking for some top level guidance. Thanks.

Hi @Walker White - On the surface, your approach looks fine. To cut through the nuance, I typically ask myself before jumping in... How many teams and/or code repos will I be working within the new solution? The answer helps me understand and dig deeper into the number of: * Projects * Boards* Determining Scrum/Kanban * Do I need boards that span multiple projects? * Dashboards* Do I need to explore marketplace apps to simplify the Dashboard experience? * Advanced Roadmap Plans* Hierarchy requirements * Teams * Are shared releases necessary? The nice thing about Jira is that if you start down the wrong path, it's pretty easy to adjust your architecture to fit changing needs (especially early on).

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What is best practice for setting up Jira to support SaaS product development

Walker White

Per the question above, I'm curious on opinions about the best way to use projects, components, versions, releases, etc. when building a SaaS product. As you might expect, the product consists of a platform (that includes key capabilities like security, data integration, reporting, etc.) and a number of applications that sit on top of that platform.

Should we do:

Project: Platform
- Component: Security
- Component: Data Integration
- Etc.
Project: Application 1
- Component: Component of App 1
- Etc.
Project: Application 2
- Component: Component of App 2
- etc.

Or is there a better way? We have Jira Software Standard right now, but we're evaluating Premium to get access to Advanced Roadmaps. We'll need that to do capacity planning, etc.

I'm certain there's a lot of nuance, and we're just looking for some top level guidance. Thanks.

Accepted answers

Mark Segall

Hi @Walker White - On the surface, your approach looks fine. To cut through the nuance, I typically ask myself before jumping in... How many teams and/or code repos will I be working within the new solution?

The answer helps me understand and dig deeper into the number of:

Projects
Boards
- Determining Scrum/Kanban
- Do I need boards that span multiple projects?
Dashboards
- Do I need to explore marketplace apps to simplify the Dashboard experience?
Advanced Roadmap Plans
- Hierarchy requirements
- Teams
- Are shared releases necessary?

The nice thing about Jira is that if you start down the wrong path, it's pretty easy to adjust your architecture to fit changing needs (especially early on).

All comments

Mark Segall

The answer helps me understand and dig deeper into the number of:

Projects
Boards
- Determining Scrum/Kanban
- Do I need boards that span multiple projects?
Dashboards
- Do I need to explore marketplace apps to simplify the Dashboard experience?
Advanced Roadmap Plans
- Hierarchy requirements
- Teams
- Are shared releases necessary?

The nice thing about Jira is that if you start down the wrong path, it's pretty easy to adjust your architecture to fit changing needs (especially early on).

Walker White

@Mark Segall Thanks for your reply. To answer the questions above, assuming we went down the path of 1 project for the platform and 1 per app, I imagine we end up with less than 8, likely less than 5 for a long time.

Boards: Primarily scrum, and I'm not sure if boards need to span projects. A given release might need to, since adding a feature to an Application 1 project might require an enhancement in the Platform project. Does that mean a board needs to span projects?

Dashboards: Avoid if I can

Advanced Roadmap Plans: Not sure about hierarchy. We probably will eventually have one team per project, but initially there is/will be a lot of cross over. Shared releases? Is that answered per my Board response? I can see the Apps be dependent upon Platform, but Platform should never be dependent upon an App (seems like we'd be doing something wrong in that case).

Any additional input welcome. Thanks for taking the time.

Mark Segall

Does that mean a board needs to span projects?

The only time you typically need boards to span across projects is when you have a single team responsible for multiple projects. This is common in micro-service implementations where you want a project for each code repo, but it's still the same team that manages the overall solution.

Not sure about hierarchy

This is where Advanced Roadmaps provide the most value - tying Epics to business objectives. You establish a hierarchy of issue types above the Epic, usually tied to various tiers of OKRs within the organization (e.g. Organization OKRs >> Department OKRs >> Epics >> Stories). This makes the plan more digestible to leaders as they focus on the 30,000 foot view with the ability to drill deeper on OKRs that appear to be at risk.

Shared releases?

In a nutshell, releases are specific to each project. However, Advanced Roadmaps provides the ability for a "shared release" which simply creates the same release across each project, basically saving the admin from having to repeat the step multiple times and giving a view like its one release on the plan. However, each release still needs to be maintained individually.

Walker White

@Mark Segall Thanks so much. Great info for us to get started.

anna drozd_pmvrdn

Great discussion here on optimizing Jira for SaaS projects! When developing SaaS, having the right project management setup is crucial to streamline workflows and ensure smooth collaboration. For anyone looking to deepen their understanding of the developing SaaS process and best practices, this comprehensive resource on developing saas is definitely worth a read.

Sanjay Singh Rajpurohit

I'd keep the Jira setup as simple as possible at the start. If Platform, Application 1, and Application 2 are managed by largely the same teams and follow similar workflows, I wouldn't create a separate project for each one. That can quickly turn into a reporting and dependency-management headache.

I'd probably use components for areas like Security, Data Integration, and Reporting, and use epics for larger initiatives that may span multiple parts of the product. Versions/releases should represent actual release milestones, while stories and tasks handle the work needed to get there.

One thing I've seen in SaaS projects, including work done by teams like Technource, is that Jira works better when it reflects how the team actually delivers the product rather than trying to mirror the entire technical architecture. Use it to make ownership, priorities, dependencies, and delivery visible. If Platform and the applications eventually have different teams, workflows, permissions, or release cadences, that's when I'd consider splitting them into separate projects.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud