URGENT! Different teams + Same project + Different workflows?

[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?

1. 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)?
2. Should I create just one project and different boards to each squad?
   • Here I can't imagine how to solve the "different squad workflows".

[John Funk · Accepted solution]

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. 

[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?

[Dionei Piazza · Accepted solution]

Hi @Fernando Bordallo and @John Funk 

Very helpful answer! You gave me good insights! 

Thx!

[John Funk]

Great! Glad we could help.

[Fernando Bordallo · Accepted solution]

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]

@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. 

[Dionei Piazza]

Fact @John Funk ! 

I'm new here, but I dare say that Actionable Agile is fantastic! 

[Meytal BM]

@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]

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

[Meytal BM]

Hi @Dionei Piazza  thanks a lot for your elaborated answer. Really helped me think things through.

For now, for each team (aka Squad) i have decided to go with a diff project. There are teams that we're still debating whether to create a diff project for their sub-team, but I will know later this week depending on a design session I will do with them.

As for dependencies:

1. We have a cross project identified (aka custom field) that if it is set on an epic, we know its part of a larger project. Then we can use Looker or other reports to show the portfolio view.

2. Each team who has dependencies will need to collaborate on a quarterly level and if needed, more. Either way, in Jira they will each open their own epic with that cross identifier.

3. Dependencies within the same team, but diff sub-team, there will be one epic owner, but the stories will be assigned to specific person, and we have another custom field "teams" so we can also see on a team level the item(s).

So far, I have tested some of this, but I am literally at the implementation stage of all the teams/squads, so once they start using it (in the next month+) we'll find out what works great and some areas that need adjustments.

Hope this also helped you and others.