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; } } }

Project Establishment Strategy Question

Frank Chi

Strategically speaking, is it better to establish a Jira project for each team or is it better to establish a Jira project for each product or software system that we develop? Our motivation behind this is to break up the work into smaller easier to manage projects.

I am particularly interested in Jira's capability in linking workflows which are in different projects into a cohesive overall workflow as the different teams often work together or hand off work between the teams. I don't yet know enough about Jira to decide which strategy is better for our situation where a lot of our work requires that multiple teams work together on projects, each with their own detailed workflows which when linked together defines the larger workflow.

Accepted answers

Dan Breyen

Welcome @Frank Chi ! We had different development teams working on different applications. With that in mind, We have different projects for the different applications.

I would say it depends on the size of your teams. Jira has the functionality to move issues to different projects, but if you have a smallish team, you might be able to get away with using components to differentiate versus complete projects. With that said, you don't want to get your developers upset by having one project that's too big to find stuff in, where individual projects may be better suited for your needs. I've worked in big and small shops, the preference tends to be different projects for different applications.

That's my two cents, take it for what it's worth!

All comments

Dan Breyen

Welcome @Frank Chi ! We had different development teams working on different applications. With that in mind, We have different projects for the different applications.

That's my two cents, take it for what it's worth!

Frank Chi

Thanks for your feedback! I also think that it is better to organize a project around a product or application (or a service offering), given the somewhat limited capabilities of the workflow capability provided by Jira.

Basically, a workflow should be an abstraction that represents a work process that is comprised of work elements (atomic or composite) along with assigned resources (people or otherwise). If I was a king for a day, I would beef up the workflow capability in Jira by adding what I would call a WorkflowGate.

Workflow gate should be able to implement three types of transitions at a minimum:

a. The simplest transition is a single thread finish-to-start where two work elements are related in a simple relationship where upon one finishing, the next one starts.

b. Fan-in transition is one where multiple work elements must all complete before the next work elements can start.

c. Fan-out transition is one where multiple work elements can start simultaneously to work in parallel.

The workflow should be able to straddle projects and work elements in a workflow can each belong to different projects. In this way, both team-oriented projects and product or service oriented organization of projects can be supported without compromise.

I have too many opinions. I apologize.

Brian Beaton

No this is a great point, such as a product development where a Core API function is required for multiple features in the application interface. This being an example of your Fan-Out transition.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

team-managed-projects