Guest Contributor: Isaac Sacolick, President | CIO, StarCIO

It’s unfortunate when a technology is too complex to configure, too difficult to use, and end users underutilize its functionality. But in my experience working with Jira Software and Jira Service Management (JSM), the platforms’ flexibilities and ease of use drive increasing adoption. That’s the good problem, but it begs the question of when and how to clean up a growing platform, create standard ways of working, and still provide flexibility when required. 

A real-world Jira adoption scenario might look like this. Several teams start using Jira to manage their scrum backlog and workflow, and just a few years later, there are dozens of groups using it with hundreds of projects, workflows, fields, and reports. 

Similar growth happens in JSM, where usage might start with the end user computing service desk and a handful of services. But the success of managing these services in JSM drives adoption in other groups such as cloud support, InfoSec, and other enterprise service management functions.

In the webinar, Five Rules for Cleaning and Organizing your Atlassian House, we answer several questions on recognizing when you have a growing mess, why duplicate and chaotic configurations slow down organizations, best practices on creating services in JSM, and how to consolidate workflows. 

But in this post, I want to present you with options on how to think about Jira Software Projects. Specifically, how should you think about projects in the context of teams, agile product owners, services, workflows, and reporting? Or said another way, when should you create new projects, and when is it time to clean them up?

What are Jira Projects?

First, I’d like to acknowledge that Jira “Projects” are poorly named as many organizations focus on delivering products, services, automations, applications, and other business deliverables. More importantly, agile teams continuously plan releases, ongoing enhancements, and longer-term roadmaps, not one-and-done projects.

But let’s get tactical and look beyond the word "project," because configuring a Jira Software Project provides access to a backlog and an active board for people to do their work. 

So, above all else, a Jira Software Project should help the people involved update the status of their work on the active board and see upcoming priorities in the backlog. The requirements are stored as Jira Issues, organized into Epics, linked to other Issues, tagged to releases, and managed through a workflow. 

5 Rules of Thumb for Creating Jira Projects

It sounds simple enough until you reconcile Jira Software Projects with the team, the scope of work, who prioritizes the work, and how the work gets done. 

There are many ways to align the organization, priorities, and workflow, so I am sharing below how I’ve led agile organizations and how StarCIO guides organizations in our agile centers of excellence. 

Rule #1:  One Team, One Product Owner, One Jira Project

This team can follow Scrum, Kanban, or another workflow, add or subtract team members, or reassign the product owner role when required. This means the team has one place to look at their backlog and active work, and product owners manage the priorities in the backlog. The team can also shift focus across products, applications, and services and remain as one team using one Jira Software Project.

Ahh, but it’s not that simple, and many of the exceptions occur because of how tech teams organize. 

Rule #2: Use Proxy Product Owners for Shared Service Teams

If a team has more than one product owner trying to assign priorities, then work with them as stakeholders. Two product owners debating and shifting priorities is inefficient and leaves teams guessing what to prioritize. 

Instead, designate one team member to act as a proxy product owner of the team’s backlog and provide transparency on backlog prioritization’s rules and methodologies. A technical lead, scrum master, or business analyst are all options for assigning the proxy product owner responsibility. 

Rule #3: Delivery Managers Finalize How Teams Organize

So what happens when a program, product, or other deliverable requires a large development group? We can debate how many people max out a two-pizza-sized team, but when programs require multiple teams, who finalizes how teams should organize?

This topic is debatable, especially for organizations that fully subscribe to self-organizing teams. When teams have complete autonomy, it can lead to shifting strategies on whether four, eight, or ten teams are the optimal model to organize forty people. The experimentation can lead to lots of spinning up Jira Projects, and let’s face it, we’re not as disciplined about shutting them down. 

In a similar vein, I don’t believe it’s in the product owner’s responsibilities or skill set to decide how to organize. They are stakeholders in this decision because if you choose ten teams, then the product owner has as many backlogs to manage.  

So who has the final call? In StarCIO Agile Planning, we assign this responsibility to a Delivery Manager who has oversight across multiple teams. Delivery Managers must have excellent listening skills, and have a strong understanding of the product vision, the prioritized roadmap, the underlying architecture, and teammates’ skills and interests to make these decisions. One key factor is to minimize dependencies between teams which is one reason why organizations invest in microservices and test automation.

Once there is a team structure, it may require revisiting the alignment with product management and owners. If many teams coordinate work, then it’s a good time to review Advanced Roadmaps or expand to Jira Align.

Rule #4: Customize Boards and Dashboards for Team Consultants

Here is where I am a purist. A person is on the team, commits with the team, demos at the team’s sprint reviews, and participates in retrospectives – or the person is not on the team. A person who works part-time for a team is a consultant, and consultants may work with multiple teams. 

One option to help consultants see their work is customizing Jira Boards that use JQL to filter their work and Dashboards for collaboration. Another option is to use JSM, create a Service for consultants, and manage their work as tickets. The latter option works well if you create automation connecting JSM Tickets and Jira Issues.

Rule #5: Use Jira Software and JSM’s Full Capabilities to Model the Work

Thus far, the constructs I’ve presented help product owners, teams, and team consultants organize their work.  

But one thing that can create messy Jira instances is when you try to do more with Projects rather than using other capabilities in Jira Software, JSM, or other Atlassian tools. For example, you can alleviate some pain by:

• Using JSM to create a work intake or request form and separate this process from the team’s backlog
• Using Jira Components to align teams and Jira Issues for technology components, including apps and services
• Standardizing on a manageable number of workflows, a topic covered in the webinar
• Using Advanced Roadmaps or Jira Align to roll up information to business capabilities, strategies, product families, products, or services
• If the reporting in Jira Software is insufficient, using a Tableau connector, a Power BI connector, or other reporting capabilities in the Atlassian Marketplace

These are all good rules, but large and medium-sized organizations also need a governance group to put them into action, decide when to clean up, and steer teams toward standards. Tune into the webinar to learn more about creating a governance group.

Isaac Sacolick, President of StarCIO, guides companies through smarter, faster, innovative, and safer digital transformation programs that deliver business results. He is the author of the Amazon bestseller, Driving Digital: The Leader’s Guide to Business Transformation through Technology, an industry speaker, and blogger at Social, Agile, and Transformation. StarCIO offers three agile planning courses for stakeholders, teammates, and certified StarCIO Agile Planners.