Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Should I create projects per team or per product? My small team works on every product

I have a small team of designers and researchers and we are delivering assets for marketing while working on 4 products.

I want to set up Kanban boards for us to track to work and to have an overview of capacities. In the company before - we had dedicated designers per product, so they had their own project together with devs. 

I'm not sure if I should create projects per product - it will defy the purpose of tracking capacities and workload - but will be better for scaling. Or if I should create one project for design and one for research where tasks of any type would go there, and then change the approach once we grow.


Any thoughts or links to articles?


Thank you!

1 answer

1 accepted

1 vote
Answer accepted
John Funk Community Leader May 13, 2021

Hi Peter - Welcome to the Atlassian Community!

Our philosophy is to create a project per distinct team. If you have the same people working on multiple products, we tend to create a single project in Jira and then create Components for each product. 

Then you can create a single Master Board for showing all work and multiple boards - one for each product - where each board is based on the value of the Component (i.e. Product). 

That approach would work best with a Company-managed project. 

I hope that helps a little. 

Hi @Peter Kocur -- Welcome to the Atlassian Community!

Adding on to John's suggestions, whichever way you decide to *store* your issues in Jira for teams' work, try to visualize it on one board per team doing work.  That helps the team with focus, transparency of progress to stakeholders, and can support conversations of JIT work disrupting people's expectations on delivery.

And as John also suggested, when you need a roll-up view for larger initiatives, use a separate board for that, and treat it as read-only, leaving the updates to the teams on their respective boards.

Best regards,


Hi, @Bill Sheboy @John Funk thanks a lot! I thought I'd create a project per product and then create a board from a filter that would combine those projects. I want project managers to own their own projects in Jira later on. They could create issues per their product for either design or research, and we would have them shown on our board. This feels more scalable for me than to have one project for Design and one for Research. Since both design and research are always working on products, it also seems that it can promote silos? But I might be getting this wrong. Any thought on this approach?



Hi @Peter Kocur 

Yup, specialized-skill, service team work (e.g. UI, UX, Research, Architecture) is often difficult to manage when a company doesn't have enough of those people to justify/assign full-time to each team.  (I've only worked at one place that did :^)

You and your teams are going to have the most accurate info to decide how to deal with this.  Some different approaches I have used with Jira/Jira-like tools, each with their own pros/cons:

  1. Service-team people are temporarily assigned, full-time to the project team, and so their work is in the teams backlog/board.  This is usually driven by the project's specific work needs.
  2. Service-team people use work intake processes to manage requests from project teams, and keep all service-team work on the service-team project/board.  This allows them to do enterprise-level work on their board and balance it with requested project work, and requires a company, shared understanding of priorities so the service team isn't pulled in different directions.
  3. Variation of #1 and #2 service and project teams have their own backlog/board, and loosen up their Jira board filter(s) to show work they do in support of projects (multi-project filter)

One key to help is understanding your company project WIP.  When focused on one/a few initiatives at a time, it is easier for everyone to focus on that.  When there are lots of parallel efforts, you need a work management/visibility approach to help with that.

John Funk Community Leader May 14, 2021

Bill makes a great point about WIP. As long as you are managing WIP on a consolidated board (with multiple projects) you should be fine - again, that's if you are using the same resources across the projects. 

Hi, @John Funk @Bill Sheboy Thanks guys! I'll go with your original proposal to have one project per team and use components. 

Like # people like this

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Service Management

JSM June Challenge #2: Share how your business teams became ITSM rockstars

For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...

321 views 9 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you