Why Jira Administrators Should Love Team-Managed Projects in Jira Cloud

Guest Contributor: Larry Cummings

I have been configuring Jira projects for many, many years. When Jira team-managed projects first came out for Jira Cloud I was excited, then kind of bummed, and then I kind of got back to whatever I was doing. That was a few years (and product names...) ago, and since then, the capability has matured and I've grown to absolutely love it. Keep reading to find out why. 

Team Managed Projects Are about Time to Value

Atlassian’s mission is to enable the power of every team. Most new Jira sites are part of an Atlassian Cloud site. This means organizations that are new to Jira can (usually) be up and running in Jira in a matter of days.

With this capability, Jira project configurations become a bottleneck, particularly for teams that are:

• Very new to Jira
• Don’t have Jira Administration skills (yet) to configure company-managed projects quickly
• Need to start using Jira prior to learning how to configure company-managed projects
  
  

Team Managed Projects Help Teams

With a very rapid deployment model, Atlassian also needed to provide a very rapid Project Configuration capability. This has dramatically improved how useful Jira is to new teams, especially non-technical teams.

By adding team-managed projects, new Atlassian teams can now choose from over 40 different project templates and of those, only 9 of them assume a Jira Administrator will have to configure the projects with the teams.

Following are some important things to keep in mind when using Jira team-managed projects.

It's important to set expectations for team-managed projects.

Socializing why and how a large enterprise uses team-managed projects is important, particularly if your organization is not new to Jira, but is new to Jira Cloud.

When we give our teams the ability to modify their project configurations directly, that changes the way we think about Jira project configuration and administration in the cloud. This will happen very quickly if the Jira Cloud site has a need to use a mix of team-managed projects and company-managed projects.

However, team-managed projects do have some limitations. These limitations happen because team-managed projects are designed in a way that a new team can create and configure a project however they want, without having to learn anything about Jira company-managed projects and schemes.

Custom fields and issue types are managed completely independently by the team.

You can’t have a Custom Field that’s used on both team-managed and company-managed projects, and the same goes for Issue Types. An Epic created in a team-managed Jira Software project is not the same Epic issue type you use in a company-managed Jira Software project.

This means...well, this is why we have to think differently about Jira Administration in the cloud.

The custom fields your teams create in their team-managed projects will not be listed in the Jira Admin -> Issues -> Custom fields list, which helps. You will also become VERY attentive to which project reports you're looking at. We should expect teams to want to use the same custom field names, and issue type names, as you will see in your company-managed projects.

How big of a deal is that?

If a team wants to use a team-managed project and there's no process governance reason that they “won’t be able to do the custom process configuration themselves,” why should I say yes or no? So I came up with this diagram:

I don’t want to get into a “how does the software need to work” level, though software architectural reasons are absolutely important. After initially being pretty bummed out about Issue Types and Custom Fields being distinctly different objects, the time to value always won. More specifically, what the team could get done using Jira while we figured this out was almost always more important than which configuration approach was going to be perfect. I've learned to love all the things that help my teams get work done. So, that's why I love team-managed projects now.

Further Reading

It’s important to help teams understand when we should or should not use a team-managed project, which is why I always work on a governance exercise with them. That way, there are no surprises.

Things to keep in mind if you migrate from company-managed to team-managed

This direction, moving a team from a company-managed project to a team-managed project is actually very easy, but It’s not useful for teams that are using a very codified, shared process. “Classic” Jira Agile/Lean (Product) team configurations are still preferred and “always” will be. Specifically, teams that use Jira Software seats, and SCRUM features, will not be able to convert their sprint information (future or past) to the team-managed project sprint capability.

That’s not very surprising as sprint cadences for teams are quite often process tuned to ensure consistent reporting and agile/lean process boundaries are codified in the tool.

Teams that are using Jira Service Management (JSM) projects will not be able to use team-managed projects to communicate with customers on requests, (the core, necessary feature required for a JSM Agent seat is that user’s ability to communicate with customers on requests in a JSM Project). Most JSM projects are configured by default to be effectively team- and admin-managed in terms of their using independent schemes and unique project administration features.

Things to keep in mind if you migrate from team-managed to company-managed

This is the direction we see quite a lot of and the news is mostly middling here.

On one hand, there’s a great deal of interest in letting the teams figure out their own best configurations before you start talking about “norming” up configurations for consistent reporting.

On the other hand, there’s the concern that a team will create such a unique configuration that it won’t be feasible or painless to convert it to a company-managed project. If this is the biggest risk, it’s really a matter of asking if it’s worth the effort required to convert the data at all, or if it would be better use of everyone’s time to simply ask the team to stop using their team-managed project when the company-managed project is ready for them.