Project and Team structure conundrum

Don Hames

Our Jira Software Cloud instance has differing opinions on the following:

1. One project with many teams

2. One project per team

Currently, there is no consistency in the implementation of these two approaches. I think I know the pros and cons of each, and I know how to configure Jira for either method.

We are in the middle of ramping up to Scaled Agile and have had some success already. In the name of organization and structure, I would like to pick the method with the most benefits and have all Teams and Projects follow the same construct.

What experience have you had with these two methods? How did you make your decision? As I enter into the organization and structure phase of our Jira Software Cloud, I want to choose the method that benefits the teams most, Agile metric reporting, etc.

Ok, the floor is open, my fellow admins! I would appreciate any input and suggestions you have that I may not have thought about. Thank you so much for sharing your knowledge and experiences!

Walter Buggenhout

Hi @Don Hames,

A lot depends on what your organisation looks like, what type of work they do, how work is submitted to or defined by your teams and so on. Also: are you able to clearly identify a team in your company? Is it on the org chart? Is it formed around a product? Focused on service delivery? Or a platform team which core mission is to support other teams doing their work? Or are teams random groups of people brought together for a project and after the project ends, the team ceases to exist as well?

From an administrator perspective, I clearly understand the benefits of having a single approach for all: it makes things clear, manageable, even comfortable in a way.

But in the triangle of people / practices / tools, tools should be the least important element. Today's organisations tend to be complex, fluent, ever changing. And that makes it hard to impose a one size fits all approach to your toolset or configuration.

One thing I strongly believe in is that you should start with the teams (the people) in mind. Make sure they have a single board for their work. If it is coming from one or multiple projects is less important - that will be largely defined by what the team is doing. On top of that, if your organisation is not too small, you'll need to find ways to unlock shared insights. Things like status categories, cross-team roadmaps, a shared project portfolio and most of all, communication and shared understanding of goals and context are important pieces in that puzzle. Trying to scale your team collaboration is always a balancing act between autonomy and alignment. Align where you should, give autonomy where you can. It's what makes people happy.

Hope this helps!