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.

[Mark Segall · Accepted solution]

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).

[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]

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.