The Admins of Atlassian Podcast

A podcast for administrators that support Atlassian products and ecosystem with a focus on JIRA.

E11 – Jira Project Structure

by Leave a Comment

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | RSS

In This Episode

In this episode, I share how I structured my Jira projects as a newbie admin and share tips that you can use when structuring your Jira data.

Products

This episode focuses on the following products:

  • Jira

Links

Episode Credits

This episode is hosted, produced, and music by Mark W.

Disclaimer

All thoughts, comments, tips, and best practices shared by the host and or guests of the Admins of Atlassian Podcast do not reflect the views of Atlassian nor do they replace procedures and steps officially provided in the Atlassian product documentation.

Transcript

Intro

I’m hunched over, boxed within the make-shift walls of my cubicle. Jira is installed on a spare machine backed into the corner of my cube. Each whir and click of the machine begs for more resources. I perk up at the email notification in the top right of my screen. It’s another email from a developer. Another request to use Jira.

I log in to Jira and navigate to my projects screen. The scrolling doesn’t stop. There are projects upon projects. Each project correlates to a developers source repository and I keep being asked to create more.

It has never been more apparent, that I need organization. I need a way to control this chaos.

And so, I asked myself, and I asked the internet “What is a Jira project?” and “How do you define it?”

JIRA Project Structure

Welcome back, to another episode of the Admins of Atlassian podcast. Today’s topic is all about project structure and defining exactly what a project is or at least I share how I defined it for the Jira instance I administrated. I hope that by the end I would have given you some ideas or at least prompted you to think about how you’ve structured or will structure your Jira projects.

When starting out, Jira was being used strictly by my development team. In the early pilot of Jira with developers, I simply set up a Jira project for whoever requested it and for whatever codebase it was for. This lead to many, many projects and I could see how quickly things could spiral out of control.

And so, I began searching online, and I found that there was only 1 recommendation. That was to define the Jira project for however best your organization works. This was a given, but I needed to see HOW others did it. So, I kept digging online and I would ask others at Atlassian User Groups. What I found was that no one had a structure! I’m sure there were people out there that devised a structure for their Jira project organization but all that I found were others doing the same as me, chaos.

Ultimately, I decided to ‘go with what I know’ and looked within for my much-needed answer and decided to structure my Jira projects based on how the code bases were set up.

We were using Jira for bug tracking and later development, and support teams were interested in using it as well so I started with two categories in Jira; Development & Support.  These categories would be what I would assign a new Jira project to. There was also the added benefit of being able to search by category as well if we needed to generate any stats.

Next up were projects.

Mark’s Project Structure

First, the term projects in Jira confused many. In our world, projects meant development projects or a project to organize a cabinet. In Jira world, that wouldn’t apply. If I created a Jira project to match whatever project was active in the organization, you wouldn’t be able to find anything! I ultimately decided that Jira projects would be defined as an application, product suite, or service provider. Let’s break that down.

Application

First application. I would create a Jira project for each application. For example, if my application was Amazon, then I would have a Jira project called Amazon. So when developers worked out of the Amazon code base, they would tie their code commits against the issues from JIRA project Amazon. This would also mean that when releases for the Amazon code base occurred, there were no other dependencies. Everything was 1 for 1 in a sense. Everything you needed for the Amazon application existed in that singular JIRA project.

But what if your code was modularized or its many different pieces made up a whole?  That is when I would use the Product Suite definition.

Product Suite

A JIRA project for a product suite contained one too many applications. These were all tightly integrated. Maybe not in sharing the same code base but maybe sharing the same core and they also had interdependencies amongst each other. This meant that they shared the same release cycle as well. They weren’t released independently, you couldn’t release product a without product b. Because of this, I would create a JIRA project for the product suite.

For example, I will have a JIRA project called Tesla Model S. This is not going to be a good analogy but hang in there with me. I have a JIRA project called Tesla Model S. Now, to build this car, lots of different components need to be built and then assembled together before I can ship the car, right?  The wheels are designed and built. The seats are shaped and clothed, the windows are cut to specific measurements, the dashboard is inserted. The car goes down the line, each piece separately developed are then added to the whole.  Ok, not a good analogy but I hope that puts into context of what I would call a product suite.

Using the product suite concept not only helped reduce the number of projects that I had, but it made life easier for release managers or build engineers tracking changes. Because they shared the same JIRA project, we would use components to split out the application affected and the area of the app. The versions, because it was all released together, was used for them all, meaning one place to maintain components and versions. If the applications were split across 5 JIRA projects, then that will be 5 JIRA projects to maintain components and versions for searches and reports. Not to mention workflows and other project and issue type customizations that may have been needed.

So, if it met the criteria, product suite was the best fit.

Service Provider

Lastly, there were the service providers. This generally referred to support and other non-development teams. If you received a request to complete a task, then you were a service provider.  A lot of the requests were in a silo. There was no other related work done by other areas and often a particular team or department was solely responsible.  In other times, multiple teams did the same work or touched the same piece of work. This became a great discovery process and some teams were ultimately consolidated to a singular support project in JIRA.

What if you are not a support team and you are HR or Finance, or Marketing? A user isn’t submitting a request for you to complete a task, you’re defining your work and projects?

It’s ok, this works as well. You can have a JIRA project for HR, for Finance, for Marketing, for Audit, for Internal Projects, it doesn’t end. The most important part is to look at your structure and ask, where does it fit. Is this now a new category of organization in JIRA?

Mark’s Project Types

Earlier I noted that I created two categories in JIRA, Development & Support. In my structure, Application and Product Suite fit into the Development section of my project categories while service provider varied. it could be Support or Finance. It was a great way to organize my JIRA projects but did I do anything more with it?

Yes, I did.

When JIRA projects were being requested, my team and I would ask all sorts of questions, the most important being “What and How will this project be used?”

These questions helped us determine how it would fit within JIRA and depending on their response to other targeted questions, we would know if the project needed to follow a template.

In JIRA we kept project templates. These were empty projects that were outfitted with the necessary workflow schemes, field config schemes, and screen schemes for that category of work. If it was a Development related project, then it received the Development Template. This ensured certain requirements were put in place such as how we handled or tracked for Bugs. If it was a Support project, then it was generally more lax or lacked any required configuration. It received the out-of-the-box workflows, screens, and field configurations. If it was support for development, again, it followed a strict workflow for certain issue types, and changes were limited.

Having project types in this manner helped streamline project creation and configuration. I went from chaos to structure.

What About Official JIRA Project Templates?

But, what I just outlined to you was how I set up, defined, and organized my JIRA projects. This was all defined and massaged from the early days of JIRA 4.x to JIRA 6.x. What about JIRA, now?

Over time, JIRA has been adding templates to its suite of functionality. This came from specifying a scrum template via the old Agile plugin to specifying if you were a business, software or service desk template. Each gave you differing underlying changes.

Business Templates

Let’s start with the business templates. You have three options:

  • Task Management – The simplest template. You get a very basic workflow and screen here as the focus is on basic task management with a To Do and Done workflow status.
  • Project Management – This adds an In Progress workflow status and a few more fields to the issue. This is intended for long-running issues with estimates.
  • Process Management – This is the more complicated piece adding in varying approval and rejection states to the workflow.

Software Templates

  • Scrum Software Development – This is a simple workflow with To Do, In Progress and Done workflow statuses.
  • Basic Software Development – This adds In Review status to the workflow as well as the Improvement and New Feature issue types.
  • Kanban Software Development – This workflow makes the default status Backlog and moves that progression forward.

Service Desk Templates

  • IT service Desk – Focuses on ITIL, with default issue types for the most common problems and or requests such as Incident or Service Request.
  • Basic Service Desk – Covers basic help desk requests for non-technical needs such as Access, or Purchase.

Another feature when creating your project and selecting its project template is to select to share its configuration. Doing so will let you pick a project and it will reuse the workflow, screen, and field configuration.

Closing

How did you define what a JIRA project is? Or do you have a definition of what constitutes a JIRA project in your organization? Do you think this will be something that will help you contain the chaos of your JIRA projects?

Let me know on Twitter @admnofatlassian. That’s admin with no I. I’m always fascinated with seeing how others have organized JIRA and their thought process behind it.

In The News

Before we go, here is what you should know:

Bitbucket Server

Bitbucket Server 5.5 has been released and includes personal access tokens and rebase workflows.

Want to integrate with other applications, personal access tokens can be created replacing basic auth passwords. Personal access tokens are created on a per-user basis and inherit the same level of permissions as its token creator.

You can now rebase as part of your workflow in Bitbucket Server. In 5.5, developers can opt-in to a new pull request merge strategy that allows you to rebase and merge your changes. Be sure to check the link in the show notes for a video demo on how this new feature works.

Confluence 6.5 Beta

Do you like betas? The first beta for Confluence Server 6.5 has been released.  This beta currently includes changes for easier database setup for new admins to get started in connecting an external database. 6.5 beta also includes improvements to attachment indexing performance. You can check all this and more via the link in the show notes.

Blog – Scaling Jira Software

Last but not least is a blog post read from one of our own at Atlassian and my fellow Atlassian User Group leader – Kim Wall. She has a fantastic blog post titled “The human side to scaling Jira software: governance, change control, and more.”

Sign-off

Thanks for listening to The Admins of Atlassian’s podcast, I am your host, Mark Williams. Be sure to check out the show notes for links to all the information I talked about. If you are new, be sure to subscribe to the podcast in Apple Podcasts, Google Play Music, or through your favorite podcast app. Don’t forget to leave a review and share with your fellow-Admins. Join me in two weeks, for another new episode.

Until next time.

 

Reader Interactions

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.