I need expert advice on a question regarding the project setup in my organization!

[Vijay Kumar]

Hello All,

When I joined my current organization as a Scrum Lead, I noticed an issue with the project setup. We have one large project called CDP, under which various teams like Jaws, Chronos, Chimera, Apollo, and Hercules operate.

When these teams create a user story, CDP as the project is already set by default in Project Settings. To differentiate their team stories, they assign the story to their team using the 'Assigned Team' field at the user story level. This ensures that the stories appear only on their respective JIRA boards.

The problem arises when I try to close my team's sprint. I can't do it unless all tasks and stories from other teams are also moved to 'Completed' status. For example, if the JAWS team has completed all its work and wants to close the sprint, we can't do so if the Apollo team still has ongoing tasks. This seems to go against Agile/Scrum best practices.

Here are my questions:

1. From an Agile/Scrum practice perspective, is it acceptable to set up the project this way?
2. If not, what are the best practices?
3. Is there a way to change this setup to allow for more autonomous project execution?
4. Are there any workarounds, such as changing current settings, so that each team can close their sprints independently?
5. I believe maintaining this status quo impacts Sprint KPIs. If so, how does it impact them, and what are those KPIs?

Please let me know.

[Lucas Modzelewski _Lumo_]

#Not an agile expert view#

If something works, focus on improving it rather than blindly following new practices—change can disrupt team spirit and undo good practices.

However, if it’s not working, fix it - maybe that’s exactly why you’re working with these teams in the first place. In that case, breaking the status quo might be the best option to shake things up from the ground up!

From my understanding, Agile is about results - getting work done and shipped to customers. If you have multiple teams (X teams) and the goal of each sprint is to deliver a release, then I’d likely stick to that structure. It provides clarity and ensures all teams work toward the same goal, with each sprint ending in a released version.

However, it doesn’t have to be this way. I’ve worked in teams where:

• Each sprint was just an increment, and releases happened when planned features were ready.
• Some sprints had two releases, while other releases came after three sprints.

If you’re wondering what to do when Team A finishes their planned work halfway through a sprint, you can always add more tasks - the goal is to get the job done! In the next planning/refinement session, you can tackle more challenging problems (higher story points) or reassess whether your story points are accurate.

Again, getting the job done should always be the priority.

__

Jira supports parallel sprints if needed: https://support.atlassian.com/jira-software-cloud/docs/use-parallel-sprints/

For training check out Atlassian’s Agile guide:: https://www.atlassian.com/agile

You can also check the community events and maybe ask some questions on live events: https://ace.atlassian.com/

[Trudy Claspill]

Hello @Vijay Kumar 

There is nothing inherently wrong with having multiple teams working on issues in one project. The best setup for your organization would be based on multiple factors such as:

1. What types of cross-team reporting do you need to do?
2. Are there any concerns with limiting team members to seeing only the issues assigned to their team?
3. Do the teams work on the same sprint cadence or different sprint cadences?

It sounds like your teams are sharing their sprints. So, for instance a sprint named "Sprint 1" is created in one of the boards, and all Teams start adding their issues to that one sprint. But it sounds like perhaps they don't really work on the same sprint cadence - they are not aligned to all complete their sprint work by the same date.

Instead each team should be creating its own Sprints in its own board. The Sprint names should contain something to identify the Team to which it belongs so that other teams don't add their issues to the wrong sprint. As long as a sprint for a Team contains issues from only that Team, they should be able to close the sprint without concern for the work being done by other teams.

Jira allows any issue to be added to any sprint. Users can edit the Sprint field directly in an issue to find any available Sprint in the instance and add their issue to it (if they have sufficient permissions).

If Teams are using boards that filter issues based on the Assigned Team, they will see any sprint in which one of the filtered issues has been added, even if that sprint was created in an entirely separate board. However, they will see only the issues from their board's filter in that sprint. If there are other issues that belong to other teams in the sprint, those issues won't show.

For this reason, distinct per-Team sprint names should be used so teams know to add their issues only to sprints that are used by their team.

Additionally it is a good idea to have an overarching scrum board that shows all issues in the project. You can then look at any given sprint and easily see if issues from multiple teams have gotten into one sprint.

[Vijay Kumar]

@Trudy Claspill  Thaks for reply. Lemme answer your questions one by one.

Question 1: What types of cross-team reporting do you need to do?
Answer: There is no cross team reporting we need to do. However, we have dependencies with each other.

Question 2: Are there any concerns with limiting team members to seeing only the issues assigned to their team?
Answer: Nope, there are no concerns like that.

Question 3: Do the teams work on the same sprint cadence or different sprint cadences?
Answer: Yes, they work on same sprint cadences. PI Planning, Sprint tenure everything else is same for all teams.

Paragraph 1: Team is not really sharing the sprint. Sprints are created and updated as per each team requirement. All teams are aligned to close the sprint on designated end date.

Paragraph 2: We never got into this situation of adding stories to other team's board, as we have separate boards created for each team. However, we are unable to close the sprint on our own & that is the fundamental issue here, which I am facing.

Paragraph 3: OfCourse we are able to add and remove stories from sprint at any point in time. Thats not an issue.

Paragraph 4: Yes, we are able to clearly segregate issues based on assigned team 

Paragraph 5: We have separate, distinct team names for each team. That is not an issue.

Paragraph 6: We have a Kanban board to track the work progress at EPIC level.

[Trudy Claspill]

Hello @Vijay Kumar 

There appears to be a miscommunication between us in Paragraph 2 where I said

"Instead each team should be creating its own Sprints in its own board. "

And your response was:

"We never got into this situation of adding stories to other team's board, "

I was not talking about adding one team's issues to another team's board. What I am talking about is that multiple teams are adding issues to the same sprint. 

Let us focus on a specific instance of your problem.

For one of these sprints that you are having trouble closing you said:

"The problem arises when I try to close my team's sprint. I can't do it unless all tasks and stories from other teams are also moved to 'Completed' status. For example, if the JAWS team has completed all its work and wants to close the sprint, we can't do so if the Apollo team still has ongoing tasks. "

What is the actual message that you are getting? How do you know that the Apollo team's ongoing tasks are the cause of the message?

The only time the Apollo team's issues could impact the closing of the JAWS team's sprint is if there are issues from the Apollo team in the JAWS team's sprint. Therefore, your teams are intentionally or unintentionally sharing sprints (putting issues from multiple teams into the same sprint).

If you want to ensure that the status of another team's issues don't affect the closing of a sprint you have to ensure that the sprint contains issues only from the owning team.