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

URGENT! Different teams + Same project + Different workflows?

Dionei Piazza · 2020-01-10T18:01:48+00:00

Hi, I'm new in Jira. I have the following scenario: * One same project (one product deliverable) * 5 squads * We use Kanban board (physical)* Our upstream has the same phases to all 5 squads. * Our downstream may has different phases to each squad (eg. Squad 1 has Deploy status, but Squad 2 don't need Deploy status because…

Dionei Piazza

Hi, I'm new in Jira.

I have the following scenario:

One same project (one product deliverable)
5 squads
We use Kanban board (physical)
- Our upstream has the same phases to all 5 squads.
- Our downstream may has different phases to each squad (eg. Squad 1 has Deploy status, but Squad 2 don't need Deploy status because it has CD - Continuous Delivery).

Given that squads have different downstream workflows, what is the best way/good practice to configure this in Jira?

Should I create different projects to each squad?
- I guess this would solve the "different squad workflows"
- With different projects, can I get an overview (metrics and a chart of all squads in one view)?
Should I create just one project and different boards to each squad?
- Here I can't imagine how to solve the "different squad workflows".

Accepted answers

John Funk

Hi @Dionei Piazza - Welcome to the Atlassian Community!

One way to solve that is with a single project and workflow like you have it.

Then create a Group for each Squad and place the members in it.

Then put Conditions on the Transitions to the phase that allows only that Group (Squad) to access it.

Another way to do it with the same project and workflow is to create a custom field with multiple select. We call it Dev Needs. Then put the optional phases in the field. The user then selects the check box for the applicable phase.

Then put conditions on your transitions again that check the Dev Needs field (or whatever you might call it) for that phase value.

That is a quick solution although maybe not all that clean. It works for us though.

Fernando Bordallo

Hello @Dionei Piazza

I'd sit more on the side of 'multiple projects', one per squad. It has great benefits and aligns with the needs you present:

easier to configure and for each squad/team to evolve their process independently
workflows, labels, field management, ... stays in the team
backlogs don't mix, which can cause additional grief for big teams split into squads
visualization across projects is as easy to accomplish as with one project. Create a filter that pulls in all active sprint issues from all the projects and create a new board from it

The issue I've seen raised in the past with this sort of system is that squads have less visibility over what the other squads are doing. We overcame this by having our squad sync up during demos.

Hope this helps you better weigh out your options

Dionei Piazza

Hi @Fernando Bordallo and @John Funk

Very helpful answer! You gave me good insights!

Thx!

All comments

John Funk

Hi @Dionei Piazza - Welcome to the Atlassian Community!

One way to solve that is with a single project and workflow like you have it.

Then create a Group for each Squad and place the members in it.

Then put Conditions on the Transitions to the phase that allows only that Group (Squad) to access it.

Then put conditions on your transitions again that check the Dev Needs field (or whatever you might call it) for that phase value.

That is a quick solution although maybe not all that clean. It works for us though.

John Funk

@Dionei Piazza - Did this answer your question for you? If so, can you click on the Accept answer button above to close it out?

Fernando Bordallo

Hello @Dionei Piazza

I'd sit more on the side of 'multiple projects', one per squad. It has great benefits and aligns with the needs you present:

easier to configure and for each squad/team to evolve their process independently
workflows, labels, field management, ... stays in the team
backlogs don't mix, which can cause additional grief for big teams split into squads
visualization across projects is as easy to accomplish as with one project. Create a filter that pulls in all active sprint issues from all the projects and create a new board from it

The issue I've seen raised in the past with this sort of system is that squads have less visibility over what the other squads are doing. We overcame this by having our squad sync up during demos.

Hope this helps you better weigh out your options

Dionei Piazza

Hi @Fernando Bordallo and @John Funk

Very helpful answer! You gave me good insights!

Thx!

John Funk

Great! Glad we could help.

Dionei Piazza

@Fernando Bordallo and about Kanban metrics?

Lead time, Throughput, Flow Efficiency, Predictability (Monte Carlo), etc.?

We know that Jira is not the best in the clarity of the reports. That's why most people use Actionable Agile solution.

Can I use Actionable Agile with multiple projects? Or in this case would be better a single project (with different boards per squads) and filter them in Actionable Agile with the labels?

Fernando Bordallo

I can't say, to be honest. I haven't used Actionable Agile before. However, the docs presented don't give insights into how it can best be leveraged. I would assume it will be driven by JQL, at which point it becomes purely a matter of personal taste. Project split vs backlog managed-split

John Funk

We just moved from Actionable Agile to Nave and really like it for metrics.

Meytal BM_tgpmuh

@Dionei Piazza I am curious as to which direction you decided to go with? Multi project or single one? And within this answer, how did u manage it?

Dionei Piazza

Hi @Meytal BM

We created 1:1, I mean, "1 squad = 1 project". Remembering that we made this choice because we have different workflows and work items among teams.

Meytal BM_tgpmuh

hey @Dionei Piazza thanks for letting me know your direction. So just so i get it right, because the teams/squads have different flows, you decided to create a project per squad?

Since we have various teams, some will have one project for all sub-teams, and some project per sub-team. It also depends if they need to use the same workflow, etc.

In regards to dependencies, what have you decided to do in this case?

Dionei Piazza

Hi @Meytal BM

Well here the answer is a little bit longer and I think we can break it down.

1 - "So just get it right, because the teams/squads have different flows, did you decide to create a project per squad?"
> Yes, as a matter of organization and maintenance effort, I've decided for each squad to have its own project.

2 - "In regards to dependencies, what have you decided to do in this case?"
> To resolve this point, the solution will depend a lot on which Jira version you have.

Here we use 100% Kanban and we have the Jira Software Standard version. To resolve dependencies, we create a custom field called "Squad". It's a list with the names of all our Product/Engineering squads. This field is displayed for all issues types. With that, a "project A", with the "squad XYZ", can inform that a certain card of that "project A" is being attended by the "squad KFG" that can be part of the "same project", or even be allocated to a different project, such as "project B".

With that, you will have to work your Reports to use this Project and Squad filter. If you use something like Nave Analytics, it will work even better!

Another option to solve this is to use the Jira Components feature.

Note:, If you have the same version as we have, remember that the Roadmap feature only works for one project. So if you want to see more than one project on the Roadmap, get ready for a license ($$$$$$) of Jira Premium that is double the value of Jira Standard, and even then, it's not a robust and flexible solution for understand Portfolio.

Was I able to help you? If you have more questions (because it's a more complex matter), you can send an invitation to a call and we'll resolve your context. My email is dionei.piazza@gmail.com

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud