Best Practices: Strategies for Defining your JIRA Projects

82 comments

Matthew Wong
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
September 27, 2019

@Foubs - You would simply create projects according to business unit.

Foubs September 27, 2019

Thanks but then where do you create your business unit ? is it only as a category or tag, not as a sort of container ?

Matthew Wong
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
September 27, 2019

@Foubs You don't create business units anywhere (although you could use user groups for that). The projects should mirror your business units themselves, which is the intent of the article. Hope that clarifies.

Lorraine Gorman December 17, 2019

-deleted-

Lorraine Gorman December 17, 2019

I thought I posted this comment but now I do not see it, hopefully this isn't a dup but it will be a shorter comment now :-P.  Our PM and mgmt team want us to move to separate projects by high level area.  Right now we have one very large project.  The ask is to move to say 4 projects so the backlogs are separate, ranking within the project areas are separate, progress can be tracked by area, etc.  Each of these project areas will have more than one team.  Deliveries and releases, however, can include work from any one or more of the areas.  This means we will need to keep the releases in each of the projects in 'synch' and release them each when one release is delivered.  Components can be customized by project in this setup but there may be a problem if anything moves between projects (the component value may need to be adjusted or added if it is in the "from" project but doesn't existing in the "To" project.  

Is anyone following a like model?  Is there a way to keep releases in synch across projects (or an add-on that helps)?  Any other gotchas with this type of setup?

Matthew Wong
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 18, 2019

@Lorraine Gorman  - thanks for touching base. There are definitely gotchas with particular project setups. As you called out, releases will be managed separately per project if you break out your streams that way. It can be a bit of a pain or manual for any particular scenario.

You might consider creating multiple boards for the same project and categorize work according to a field like component. That way everything exists within the same project, but you have separate backlogs but you can manage releases together. The drawback here is that you'd have to make sure to select a component for every issue you create, but a required field could take care of that easily. It'll also eliminate you having to worry about migrating issues between projects.

Helga Krieglsteiner January 12, 2020

Thank you for this discussion regarding release management with jira.

patsrick1943 January 13, 2020

Perhaps a project for "Company 123".

Then an epic for "Company Website" and another epic for "Top Secret IOS app", etc.

Joey January 14, 2020

anyone an internal IT dept here?  we are aligned by HR function (in jira) which is making collaborating very difficult.  brainstorming new ways to organize projects with the following requirements:

  • shared services (cyber security, training and communications, infrastructure)
  • Intact PMO looking to capture traditional metrics (start and end etc)

cc @Matthew Wong 

Kenny Peere February 2, 2020

Is it generally a bad idea to have a "front-end board" and a "back-end board"?

Oluwatoyin_Olasehinde February 18, 2020

@Kenny Peere No it is not bad. However, it is important to note that you should make it front-end xxx project and back-end xxx project... then create a board where you can have both the front-end xxx and back-end xxx project on the same board. That way, you can co-ordinate sprints for xxx project.

You can then create another front-end yyy project and back-end project yyy. Depending on your need.
However, you can also create a single project, create an epic with user stories and let the front-end and back-end devs create subtasks related to a user story in an epic, OR, they create tasks related to an epic, under the epic.
And if the task is not related, they just create tasks but not under any epic.

Rick_Barton February 18, 2020

Thanks.

Patricia_A_Webster March 6, 2020

Great overview of what projects should consider.   

Jacob Ryan Wahl October 5, 2020

A lot of great information going on here, thanks! My current company has recently adopted Jira, very excited. We work in automation, not just software. Would like some insight on how our current Jira build could be better utilized.

Currently we have our corporation as a Project. In this project boards are separated by "Job". There is one "Master Board" which includes all of the information of each other board. We have repeat customers often so each customer we work with end up being labeled as Epics.

From what I understand of Jira each Board can generate burn-down, velocity, etc interdependently of each other and the "Master Board" can generate reports based off each other job. Does each board need to be updated when an issue gets completed, I.E. Issue 200 gets completed on Board 2, does Issue 200 also need to be completed in "Master Board"? or can we slave Master Board to match what is happening in the other boards. (Sorry very new to Jira).

Do you think that using Epics to define customers is an efficient way of using the functionality? Or would we be better off creating a custom field to dictate customers. We want something that is easy without shooting ourselves in the foot long run. I would prefer to use Epics as a way of labeling requirements for jobs. I do not want to change something just to change something though. In some research I was doing a best practices recommended not using Epics as Long term unfinishable tasks. It seems Epics tie into sprints directly.

 

Thank you!

Jeffrey Derbyshire November 25, 2020

Are components deprecated in the Next-gen Software Project?

Andrea Schoel March 3, 2021

This has been a very useful thread with lots of great content. I am new to Jira Service Management and my team is trying to understand what might be the best (or obviously only) way to configure Jira projects to meet our needs. We are a software dev house and have a set of clients worldwide. Most currently submit issues via phone and email but we're getting ready to bring a very large client into sustainment and need to provide self-serve. We would also want to shift other existing clients to that model to the extent that they would want it. We currently have a small set of high touch/high volume clients but our growth is in generally smaller, lower need clients.  We're looking to set up a model that successfully support from 10-1000 clients. We also are trying to ensure our world wide internal support team can assist any customer as needed.

Currently, our development is managed in a single Project we've used for a long time with well-established processes and practices that mirror Agile dev well. The dev heads do not want us to use the same Project directly for our customer support activities, in particular the 24/7 365 incident support we are providing.  However, I haven't really found any best practices or guidance on how to set up Jira Projects to best serve customer support and, very importantly, to ensure appropriate customer info security. While our internal teams only occasionally are restricted from seeing all customer information (such as when a client has a highly confidential initiative and we're required to limit to "need to know" team members), customers can never see other customer details. While there's some benefit in them being able to search for issues that have some matching keywords, they wouldn't be allowed to see almost anything else due to the revealing nature of comments that can be put in by both customers and team members.

So, short story, I'm trying to understand if a Jira Project model where all customers are in a single Project is the best way to go or if it is reasonable to put them each in their own Project or if there's some hybrid model such as large customers over a certain size get their own but smaller customers are in one. I'm assuming regardless I need to study up on the security options and settings to enable any model so I'm really just hunting for best practices/gotchas and "do's and don't"s here.

 

Thanks!

Like Natalia A Kravetes likes this
dave1892 March 5, 2021

How does

Projects will have their own versioning or release index

tie up with organising projects as teams or business units? Do you just ignore this characteristic of projects?

In our situation I'm thinking of making the project the business unit, then each finite project being an initiative, and Epics the high level features of each initiative. 

thanks!

Like Natalia A Kravetes likes this
Sorcha Millican-Nagle March 18, 2021

Hey @Andrea Schoel I believe you can set up permissions on a granular level in Jira Software (not sure what type of project you are using), to the point of what people use/see which issues. I suppose it depends on the ease. I would recommend keeping things in the one place unless you feel you need a completely different workflow and system

 

if you are talking about customer support/issue reporting separate from development tasks I would definitely recommend that regardless, though.

Nivaldo Georg Junior May 5, 2021

Great Content!

As a consultant, that kind of material makes all the difference!

Like Natalia A Kravetes likes this
Juan Carlos June 26, 2021

Hola

Soy nuevo en Jira, estoy viendo si lo podemos usar en nuestro trabajo.

Hemos implementado una nueva plataforma de trabajo y recibimos las consultas y sugerencias de los usuarios, a la vez que la completamos y mejoramos.

Somos un equipo  integrado por tres personas, un programador senior, uno junior y yo como soporte y configuraciones menores.

Podrían asesorarme sobre si es factible que usemos jira para organizarnos?

Gracias

Like Natalia A Kravetes likes this
Marco Massarotto August 30, 2021

Here is a way to organize Projects I recently applyed to a company. Some information about the context before starting:

  • The organizational set-up of the company is mainly "traditional" (e.g.: departments, teams, business units).
  • The software is developed in an Agile way (iterative & incremental, almost cross-functional teams, continous delivery and integration).
  • JIRA Standard (so, no Advanced RoadMaps, nor JIRA Align).

I organized JIRA, so that I have:

  • Jira Projects representing TEAMs, one each team;
  • separated Jira Projects representing STAKEHOLDERs, one each stakeholder.

I considered that:

  • Stakeholders, mostly generate the DEMAND, they "request things";
  • Teams, take the demand, and:
    • refine it with the stakeholders;
    • work on it (PRODUCTION) to create value (outcomes).

I want both the Stakeholder and the Teams be able to TRACK their work, accordingly to the interests/responsibilities.

 

So, I configured JIRA to use:

  • COMPONENTs, to classify the ISSUEs requested from a stakeholder to a particular team in charge for doing it, so they have to be "MOVEd" to the team's board;
  • FILTERs to set multi-Project BOARDs, where a Team can visualize Issues that comes from different stakeholders.

Here is an example: FILTER - project = "CORE team" OR project = Traffic AND component = "Team 'CORE team'" OR project = B2B AND component = "Team 'CORE team'" OR project = "Marketing Product" AND component = "Team 'CORE team'" OR project = Technology AND component = "Team 'CORE team'" OR project = "Product Design" AND component = "Team 'CORE team'" OR project = 11576 AND component = "Team 'CORE team'"

 

What do you think?

Like Natalia A Kravetes likes this
Thayne Munson September 17, 2021

As a Scrum Master I have always advocated that a Jira project is defined by the development team rather than a specific part of the business.  The different parts of the business can easily be differentiated by Components.  My mentor always told me 'One Team, One Project, One Board, One Sprint'.  The One Sprint idea is particularly important since Jira builds velocity metrics based on sprint.  I coach a scrum team that has at least 3-4 active sprints at the same time which makes it nearly impossible to establish 1 velocity for the team which in turn keeps them from using velocity for planning future sprints.  Major scrum anti-pattern. 

Like # people like this
Michael Adams September 17, 2021

That's great feedback Thayne. 

Yann ROGER September 23, 2021

Hi all,

What is clear to me is that each Team needs its own "workplace" : issues aggregated from various Jira projects + its Sprints => 1 Team = 1 Jira project

What may not be that clear is how to set up relation between Products and Projects 

  • Products have long lifecycles 
  • Projects are changes brought to Products in a given timeframe

 

Truth may lay in setting up some kind of matrix between Products or Projects and Teams

Shari Fitz-Patrick April 4, 2022

HI,  Currently we have little projects to do with various tech improvements that are conduced across the company.  However, we would like to have one project that would house all of these improvements, eg. tech dev, front dev improvements, etc.  Would it therefore make sense to have a project that would encompass all of these and then epics that would be associated with say 'Biscuit Improvements, SOLR work, front dev, etc. that we could use to track? 

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events