JIRA Project Vs Teams - Best Practices

[Charlotte Laval Dehay]

Hello,

I'm sure this has been asked before and apologize for this. But after watching several videos on youtube and searching answers into community, I'm still confused.  

We are starting to use JIRA to manage all our IT projects, of different sizes and types, Agile and Waterfall. We have several departements; let's say five for the purpose of that question: Web Dev, Infrastructure, Applications, Integration and Data Warehouse. Some projects can be entirely assigned to a single department, but most are cross-departments projects. 

We need for the project manager and its team to be able to visualize the entire project they are working on, for each Department Managers to see the tasks assigned to their respective teams, and for the IT Director to see a High-level Road Map with the most critical projects.  

What are your recommendations to set-up projects and boards within JIRA:

1. Should we set-up 6 JIRA projects, ie one per Department and use the Advanced RoapMap to manage cross-department projects?

2. Should we set-up one Board per Department instead and use JIRA project to manage cross-department projects? We will then use project RoadMap to review the projects progress and indepedencies.

3. Would you have any other recommendations?

Thank you very much for any help/suggestions you may have,

Charlotte

[Mark Segall · Accepted solution]

Hi @Charlotte Laval Dehay - I always recommend thinking about the team experience first and working outward because those outside the team care about their efficiency first and foremost so adding overhead is counterintuitive. 

This is my go to configuration:

• Each team has its own project to be able to tactically work without interruption
  • Every instance where I've seen multiple teams sharing the same project with multiple boards has led to agony in some way (backlog blackholes, inconsistency in how you represent cross-team activity in AR, etc.)
• Departmental objectives are captured in a centralized project and configured as an issue type above the Epic in the hierarchy
  • This is done so that you can add easier control who has the ability to manage these issues

For those who have visibility into multiple teams...

• Scrum of Scrums creates a board with a cross-functional filter for visibility and/or utilize AR/dashboards
• Excutives/Product Manager - They will be able to see everything on the AR and/or dashboards

[Charlotte Laval Dehay]

Hi @Mark Segall -

Thank you very much for your answer. I think I understand your recommendations but struggle a little bit with the 'glossary'. When you talk about 'team', you're not referring to a project team but rather to a Functional team, right?

For example, we have a CRM implementation project. Within the project team, let's say we have one person from Integration and a couple of people from Applications. Of course, these people work on other projects/applications aside from the CRM implementation.

If I understand your go to configuration:

• These three people would already be part of a JIRA project depending on the 'functional' team they belong to (aside from the CRM project)
• Issues related to the CRM implementation project would be assigned to these functional teams AKA JIRA projects.
• The project Manager would use the AR and/or dashboards to see everything and, if need be, a centralized JIRA project to manage the project objectives.

Did I got this right?

Again, thank you very much for your help. 

Charlotte

[Mark Segall]

Team for me is the scrum or Kanban team that work together regardless of individual assignments. Though in ideal situations, they should all be working toward one, maybe two common goals (epics) at a time to minimize context switching and develop shared institutional knowledge vs individualized experts where knowledge is lost as they move on.

Ideal scenario aside... It sounds like we're aligned, but just in case, typing out my answer in a different way:

• The idea would be that this scrum/kanban team would all be in a single Jira project working toward their goals irrespective of project.
• Create a new issue type (e.g. Initiatives) to encapsulate all project work across teams
  
  • NOTE - I do not recommend using the nomenclature of "project" here because it can get confusing given Project has specific Jira meaning
• Create a new project that houses the issue type created above.  This will allow a portfolio manager visibility into all activity within their project.

Continuing the example of CRM Implementation...  You would create an Initiative for CRM Implementation.  Each team would create Epics on their respective project that are linked up to CRM Implementation to capture the work they're doing related to it. 

For example purposes, let's say your Initiatives project has a key of IN and CRM Implementation key is IN-1.  You could then have an AR plan with a filter like this:

issue IN portfolioChildIssuesOf (IN-1) 

This will give a nice dynamic roadmap of all child issues from Epic down to Sub-Task that have been linked up to the CRM Implementation regardless of team.

[Charlotte Laval Dehay]

Thank you Mark.  This helps A LOT!! 

I really appreciate the details answer and was able to set-up a project the way you suggested. It worked great.

[Amulya Sankara]

@Mark Segall What do you mean by Scrum of Scrums? Thanks

[John.Morales]

question, we have multiple Agile teams that are working on the same Value Stream Portfolio Project, do you recommend that we create 1 Jira Project to represent the Value Stream Portfolio Project, and create Jira Boards within the Jira Project for each Agile Team,

[Mia Paulin]

I understand.  I'm new here and am learning, so I apologize for my mistakes.  Thank you, again, for having me.