nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practices - How do you setup and work with Projects?

Andreas Lärkfeldt

First of all I love us having a forum where we can discuss how different people and organizations are using the system - even if not everything could be applied everywhere I still think the discussion is really important.

So that we actually can help the world to improve!

So - back to my topic: How are you working with projects?

I've always ended up in discussions about when and if projects should be added or if we shouldn't use projects in different scenarios.

Should you use a project as a "product" - that all "products" within a company should have their own projects?

Or should projects be connected to "teams" - a team should have their own project where they can work with all their issues.

Or should we minimize the use of projects entirely and work with Components?

So - the word is free, what do you think is best practice when it comes to working with Projects to make it easy and flawless for everyone involved?

Thank you in advance! ( And of course I have my own opinion, but I'll try to sh*t up and just listen for once :P )

// Andreas

Comments

Alexey_gudeo1

Hey, since we do software and sell it as a white label solution (banking and fintech products), we use Jise Service Desk: 1 Client = 1 organization = 1 project. This allows us to maintain SLAs, easily pass clients between agents and control access to tickets and knowledge base.

For internal task tracking, we have several projects (Development, level 2 tech support, documentation). We use 1 process = 1 project. As for the teams and products, we use components.

Components - Jira - Mozilla Firefox 2021-04-26 13..png

There are pros and cons of each method. We decided to split processes into projects, not products. Some tasks are multi-product. That approach also gives us the agility to move developers between teams (components) and tasks between teams w/o complicated tasks migrations between projects.

Vaishali Patil

Mostly, we go by the rule one codebase=1 project. This is so that we can manage the releases better.

We do land in situations where we have a team which has work to do for various project and the team like all the work show up on one place. For those situations, we do have projects just so that we can have a scrum/kanban board where we pull issues based on assignee or component from other projects.

I wish that boards could live independently of the projects. Projects could then be used mainly for defining the releases, components and any other custom fields that are product specific. Boards can then be used to manage teams or projects

Kathi Paquet

I normally setup Project = Teams. We strive to have cross functional teams for Product Areas (Value Streams) so each team captures their work related to the Epic for when starting to scale, the teams pull JIRA Epics/Features and build out their stories/tasks.

We chose teams for we want long standing teams, consistent work flow cycles, and eliminate the overhead of setting up a JIRA Project for each 'Initiative or Business Project'

Mykenna Cepek

Having worked with a dozen different organizations, scores of teams, and across various industries, I'd suggest that there really isn't a single good answer for how to use Jira Projects with/across teams, products, components, etc.

At a healthcare company, I worked with 3 teams all updating the same codebase for a single product. Each team had a different product area of focus, and each team had their own BA who operated as a secondary Product Owner. The BAs "rolled up" to the product's primary Product Owner. We successfully used 3 separate Jira projects, along with lots of cross-team communication, scrum-of-scrum meetings, etc. It worked very well, as each team had separate backlogs, prioritization, etc. We also used Epics and Releases which often spanned all 3 teams. Each team ran their own Scrum boards and their own Sprints.

Most other (smaller) organizations I've worked with tend to have a set of teams working on independent codebases with minimal-to-no cross-team coordination needed. That's a clear use case for one Project per team, even when some team members were on multiple teams.

Agile suggests that teams have autonomous control over their process, which aligns with at least "one Board per team", if not "one Project per team". That allows the team to experiment with different Board/Project settings and iterate over time to improve the visibility and flow of their work.

Larger organizations often struggle in these areas. Scaled agile approaches tend to layer the needs of the framework onto the existing teams and tools. It's far too easy to create a rigid top-down process that leaves little room for the experimentation and iterative improvement we expect from our teams.

I was intrigued by your suggestion of "working with Components" as part of "minimizing the use of projects". I've had some success with aggregating multiple teams into a single Jira Project, and using a specific field with Board Quick Filters. When this approach lines up with inherent structure in the org / team / product, it can allow all the issues to be in a single Project. Using Quick Filter(s) then focus the board on just that area, while allowing unified prioritization in the Backlog, for example.

Great topic!

Kathi Paquet

Instead of Components, we also used a custom field for Team or utilized the Portfolio (now called Advanced Roadmaps) to capture the teams.

Mykenna Cepek

A frustration I had with the Team field in Advanced Roadmaps is that it currently is not fully supported in Jira. For example, it's not accessible in Automation.

I tried to create an automation rule to set the Assignee based on the Team. Fail.

Sally Stone_5ybd5r

Great discussion! Love your take on the topic @Mykenna Cepek

I think about projects as that they are a group of "like work" which align to the capabilities of your team. This means they can take many forms based on scope, industry, objective, and org. Even within the same company, the definition around projects can evolve over time as the organization gets more agile. Like many echoed above, it's critical to align on the definitions.

@Andreas Lärkfeldt I found this article helpful for planning work w/ Jira, hope it helps! https://www.atlassian.com/agile/project-management/epics-stories-themes

Desi Nikolova

This is an interesting topic. My opinion is that how you set up projects, primarily, depends on the organisation's type and structure. It also depends on what methodologies and frameworks are used within the company.

In my experience I used to work for a digital agency where each project in Jira was reflecting on the projects we develop for our clients. So, for instance, if a client has 2 projects with us they will be treated as 2 separate projects in Jira. This allowed us to reallocate resources between different projects and we were able to track the progress on our projects independently. It was working very well and was very helpful when doing capacity planning.

Currently, I am working in a company where every team has their own products and they do a continues development. In this case, we use a separate project in Jira per team/product, where we can follow all the work per product/team. We recently upgraded to Jira Premium and started using the advanced roadmap to track progress between teams/products. Along with this we have a separate project where all business initiatives live and they are all linked to relevant teams project boards. This allows us to see all initiatives and their epic children on the advanced roadmap.