Engineering leaders we have the privilege of working with are constantly looking to improve on the operations of their team, create efficiencies, and set their teams up for success. We always think that the best place to start is with visibility into your team’s process and workflows. For many software development organizations, the primary tool for tracking the progress of ongoing projects and moving them through the workflow is Jira. And while Jira can be a powerful system, it can be complex and confusing for managing and improving engineering operations. It can be hard to know where to start in organizing Jira to work well for your organization.
In this blog series we’ll be revealing some best practices that teams use to organize their work and optimize their workflows in Jira. Guide your team to adopt these best practices and you’ll be able to significantly improve visibility and reporting, and take steps to optimize your organization’s engineering operations.
In Part 1 of this series, we’ll dig into the best practices we see when it comes to organizing projects within Jira. While these options are not exhaustive, they are the ways we’ve seen engineering organizations have the most success.
5 Jira Best Practices for Improving Your Engineering OperationsDownload the Full eBook
Best Practice: Organize your projects in a way that’s actually relevant to your business
It sounds basic enough, but too often engineering organizations don’t put enough thought into how projects are organized in Jira. Many will default to team-based projects, which while perfectly viable and arguably the most common method for organizing Jira does not suit the needs of every team.
In Jira, projects are simply a logical grouping of issues, which, by being defined together, will share common configurations, permissions, versioning, etc. Workflows of issues are also tied to projects. Therefore, when thinking about how to organize projects, it’s helpful to structure around which people (or groups of people) will be involved in moving issues through the system, who should have access to projects or see certain types of issues, which types of issues make sense to view and manage together through the workflow, and which issues should be treated similarly from a configuration and versioning perspective.
There’s no right or wrong way for organizing cloud projects in Jira, but some common methods are:
By Team: Team-based project organization is one of the most common methods for structuring Jira instances. For organizations where teams are relatively self-sufficient and work is mostly insular in nature, this model is an obvious choice in that it is logical, easy to establish, and does not require cross-functional workflows. However, for businesses that tend to face more organizational changes, structuring Jira cloud projects by team or business unit quickly becomes a burden as project settings, permissions, members, and even workflows must be reconfigured.
By Business Unit: When organizing by the team is too granular, or the work being done by teams changes quite frequently as is the case with many fast-moving companies today, some teams opt to organize around higher-level business units – for example Development, Product, Customer Success, etc. These functions commonly find the work they do falls into similar patterns and that work needs similar structures and processes in place, so this organizational model can streamline setting up workflows. But it is often the case that projects at various stages will require input from members of multiple business units. For that reason, organizing by product line can be more effective.
By Product Line: Often multiple teams or even business units will be involved in the delivery of a given piece of work. When the product or feature work is cross-functional by nature, or when teams are organized across business units, a product line-based organizational model may be most effective. This is especially useful for cross-functional teams that operate according to a common release cycle and thus consider release or versioning to be important to the way in which work is structured.
By Platform: Similarly, to organizations that break down by product line, companies whose teams are cross-functional and all focus on delivery mapped to a specific platform (e.g. operating system, social network, ad platform, etc.) may consider a platform-based organizational model for Jira cloud projects.
By Business Objective: For some organizations, work is not only cross-functional, including multiple teams, but also cross-product wherein work impacts multiple applications. Some organizations choose to group work by business objective, OKR, or company-wide initiative. As a best practice, however, we’d suggest using Initiatives or Themes to structure your projects hierarchically, which would allow multiple projects to align to the same objective, as is commonly the case.
Of course, these are just a few organizational models we’ve seen teams use to be really successful with Jira. A little organization goes a long way to improving Jira hygiene and can lead to dramatic improvements in process, reporting, and engineering operations. In the next post, we’ll cover a few more of the best practices for creating a Jira structure.
To learn more about how Jellyfish works with Jira to help drive alignment and improve engineering operations, head over to jellyfish.co.