There is nothing like that buzz of starting a new project. It’s early days, and our small team is getting the ball rolling. We have a clinical App to build, the Heart-Health App (temporary name), which will help people with managing cardiac problems. We plan to use Jira for two purposes: our development tasks and product specifications. Like this, we can create our release documentation automatically. Chad, our architect, considers the best way to configure Jira to support the two roles: product managers and developers. He has configured all the issue types we need. We will use epics, stories, tasks, tests for our development work, user needs, and design inputs for specifications.
Should all these issues live in a single Jira project or two separate Jira projects?
It is best practice to use a single project in Jira.
By default, Chad prefers to use a single Jira project. He likes to keep things simple, and our Jira has too many projects already. Also, some projects are issue graveyards or created on a whim. They overload the system, create a messy Jira experience for users, and clutter the admin area.
Each Jira project is an extra thing to manage and maintain. It comes with issue types, project role users, components, versions, etc., requiring maintenance. Chad is all for avoiding waste, and in most cases would prefer to configure Jira with a single Jira project that is easier to maintain than many projects.
So when is a single project not the best option?
Our case is unique. We are a single multidisciplinary squad, but using Jira for the two separate processes creates a particular situation.
Chad wants to configure Jira so the developers will own their process. It is up to them to decide how they groom their backlog and process stories from “TO DO” to “READY.” They could choose either Scrum or Kanban and organize their board as they see fit.
But, the process for product specifications is owned by the product managers. Their work involves information gathering from stakeholders and customer research. It requires a very different flow from the development work. When a specification is mature enough, product managers hand it over to development by linking it to development stories. Product managers provide the input for the development work but are not managing it.
Chad needs to optimize the Jira configuration for two business processes. Processes that are linked to each other but owned by two different disciplines.
Another significant difference is that our Technical File and regulatory submissions will include the specifications. While development issues are not part of the release documentation or regulatory submissions. Thus, specifications need to be kept tidy and clean. They are no place for sporadic questions and technical chit-chat. Specification issues in Jira are like the front kitchen of a restaurant: always at impeccable order and control. Specification issues in Jira are like the front kitchen of a restaurant: always at impeccable order and control. Development issues capture the brain waves of the development work. They are like the test kitchen: hectic and messy.
Chad does not want the messy development scribbles to go into the specifications issues.
A two projects configuration can be a great solution
Chad understands that this situation requires a different Jira setup. He needs to configure Jira to solve two problems: one is related to who can edit the content of the issues. The product owners need to be in total control of all the content in the specification issues. They want to prevent edit from people who are not product managers.
The second problem relates to the flow: each discipline wants to set its own Scrum or Kanban system.
The easiest way to cater to these needs is to split the two processes into two separate projects. In each project, a different group of people can get access to manipulate issues. The product managers are the only ones to have edit access to specifications while allowing everyone to view and link with these issues.
With two separate projects, each project lead can configure her board. One process does not constrain the other.
Chad knows that he could achieve these two separations in a single project setup. This will need a complex setup to configure and maintain. Hence he prefers to split the projects. Chad wants to keep things simple, and sometimes, a two projects setup is your simplest viable option.
How the two projects configuration is also helping in creating the right culture
Can you see how Chad’s configuration decision to use two projects is cultivating the right squad culture out of the gate?
He saw that within the single squad, each discipline needs another optimal configuration. He prevented product managers from feeling too protective of their specifications issues. They know that no one can meddle with their data. Product owners and developers alike will have full visibility of each other’s issues.
Chad created a setup where everybody is informed and empowered and no one steps on each other’s toes.
To summarize, when configuring Jira, use the simples solution that serves your needs. Managing all the issues in a single Jira project is the simplest solution, but some situations warrant two projects. Like our multi-disciplinary squad. If you have two different disciplines, processes and constraints, chances are, that you will be better of with two Jira projects.
