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

[Peter Kocur]

Hello!
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!

[John Funk · Accepted solution]

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. 

[Bill Sheboy]

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,

Bill

[Peter Kocur]

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?

Thanks!

[Bill Sheboy]

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]

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. 

[Peter Kocur]

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