How to use Jira as a Software Contracting Agency

Jira is built to facilitate product-focused teams, but what if you have more projects than developers?

Does this sound like your company?

• At any one time, you have many projects in various stages of your development lifecycle
• Each project may have a handful of developers familiar with the codebase, but projects do not generate enough new work to justify a dedicated team
• Your developers generally work across many different projects
• It is difficult to maintain a sense of a unified developer team, as individual developers are siloed into different projects

If any of the above resonates with you, you may have found that Jira does not make it easy to manage your business processes. Jira is built with the assumption that you have projects with dedicated teams, and many features are built with a product-centric design. However, with a bit of configuration, it is possible to organize Jira to meet your needs. In this post, I will be presenting a solution which has worked well for me in the past; it is not perfect, but it can give you ideas for ways to improve your own project management process.

Step 1: Identify developer teams

Jira expects your teams to be centered around projects, but that is not the only way to organize your developers. In my organization, the best way to organize teams was around the technology stacks used in our projects (a JS team, a PHP team, etc.). Here are a few guidelines to help with identifying teams:

1. Teams should be an appropriate size for agile development. There are various ideas as to what this number is, but a general rule is anywhere from 3-9 members. This should be adjusted to fit what makes sense for your organization.

2. Teams should be organized around a clearly defined concept. In my example, I will be going with the "tech stack," but this could be anything which is a strong unifying factor. This concept should align with the preferred team sizes; this is probably the most challenging piece to identify, but it is also one of the most important, as it will directly impact your overall team structure.

3. There can be some overlap between teams. It is virtually impossible to pick the perfect organizational structure for teams when there are more projects than team members – if it were easy, you would already be doing it. It is not a problem if a developer is a part of more than one team, but this should be minimized as much as possible.

Once you have identified your teams, it's time to start making changes!

Step 2: Start tracking teams against issues

Now that you have identified what your teams will be, it's time to start tracking that information in Jira. The easiest way to do this is with a custom field, but you can use any criteria which works for your team structure.

1. Create a custom field – call it something like "Team," or whatever you want to use to indicate which developer team it should be associated with. I recommend using a checkbox or label type field, to allow associating multiple teams with a ticket. Make sure to add this field to all projects.

2. Start setting the new field on newly created tickets. If you are eager to get started with your new team organization, you can start filling out this field on existing tickets as well.

3. Don't be afraid to associate tickets with multiple teams! Cross-team collaboration should be encouraged in this structure, and tickets with multiple associated teams will appear in all associated team boards.

Step 3: Create team boards

Once all of your current active tickets are associated with teams, it's time to create the views necessary for visualizing the data in Jira. If you've used shared boards before, you will know that it is possible to associate a board with tickets from multiple projects. However, instead of using projects for our shared boards, we will be using the criteria set in your custom field.

1. Create a new custom filter for each team. Make sure to use a value from your custom field to define the search used for the filter. An example filter I used is "Teams[Labels]" in (Mobile) ORDER BY Rank ASC, created DESC. Make sure to order the filter by Rank, as this allows you to prioritize issues in the backlog by dragging them up and down.

2. Create new boards from each team filter; you can follow the instructions here titled "To create a Scrum or Kanban board based on filters."

Make sure to share these boards with all developers on the teams they are created for.

Step 4: Create shared sprints

From the backlog view of each of your new boards, you should be able to create sprints. These sprints will be associated with the team board (as opposed to individual projects). You can use these sprints to create cross-project prioritization, and you will be able to add tickets to these shared sprints from the team board, as well as from individual project backlogs.

Once you have created a new sprint for the team board, you can start using scrum to organize your developers in these new teams. For agile processes, I recommend having stand-ups, sprint planning, retrospectives, etc. be organized by team – if you have sprint boards / backlogs up during these meetings, start using the shared board instead of individual project boards.

Step 5: Quirks and caveats

By using Jira in this semi-unintended way, there are some scenarios which can cause confusion, but each of these have simple solutions. If you run into problems, take a look at these common issues/solutions:

Shared sprints disappearing from project boards

If you like to group issues under long-lived sprints, like "Backlog Grooming" or "Ready for Development" in the shared board, you may notice that these sometimes will not appear in individual project backlogs. This will happen if you do not have any issues from the project in those shared sprints. You can remedy this by either moving at least one issue into these shared sprints from the shared board, or by creating a "placeholder" issue from each project to ensure the sprint always appears in the project backlog.

Multiple active sprints from multiple shared boards

If you have tickets which appear in multiple teams' boards, you may notice that the active sprint from one team will appear in each of the other team's shared boards which also contain that ticket. This becomes a problem, because Jira will normally only allow one active sprint in a board, and you will not be able to start a second sprint in those other shared boards. You can get around this limitation by navigating to a project where only one of those sprints is visible and starting it from there, or (for the more technical) by using your browser's developer tools to remove the disabled property from the Start Sprint button.

Putting it all together

At this point, all of the pieces are in place to start using your newly created teams. These changes may be a significant departure from your previous processes, so it is normal for it to take some time for developers to adjust. As you start using these new teams, it may make sense to adjust your team criteria as you identify what works (and what doesn't).

If all goes well, these changes should improve team cohesion, enable better cross-project planning, and give greater visibility into how your organization prioritizes and manages projects. Good luck!