I have 3 teams working on my product, front end team, back end team, integrations team, and I need to start multiple sprints for all of them (I have enabled the parallel sprints), I have created multiple teams, multiple groups, multiple dashboard trying everything I can do to have this achieved, and yet nothing is working well with me.
I have created all my stories, epics, sprints and everything on a major dashboard, but I want to break them down to the hierarchy I mentioned above.
can anyone please assist in this case?
Not certain I know what you are asking, but if each team has a board in Jira (ideally filtered by the Team field) and those boards have sprints, then this might be helpful? https://community.atlassian.com/t5/Jira-questions/Advanced-Roadmaps-capacity-planning-cross-projects/qaq-p/1574354#M461115
Hi @Hisham Balatiah ,
I would definitely second what @Curt Holley is proposing (and this is how we do it in for our teams). We also have multiple teams working from a single project and we create separate boards for each team. The basic steps to follow are:
When you group by team you'll only see the sprints for each board from the team. You're going to want to make sure that you assign the appropriate issues to the appropriate team to get this to work properly.
The nice things about this approach is that each team can have their own backlog for the work they need to do in a project - and you can still retain a backlog of all work that is yet to be assigned to a team.
I completely appreciate that this is quite a convoluted process and we're going to be looking to simplify it and I'd love to get your feedback on the current process and how we could improve it.
To start with... do you think having a board per team is a good thing (as we're suggesting) or do you think parallel sprints in a single board is a better solution? If you like the idea of a board per team, would you want to be able to create and see that association on the board itself rather than just in a plan?
It would be great to get your thoughts on this!
Hi @Dave ,
I would like to thank you for the explanation, I really do believe that a board for each team will match my needs more, as I deal with different resources, from different entities (outsourced) which they all serve and fall under one project, that's why I was interested at least to have different sprints to be run in parallel.
But I would also comment on the complexity of doing such setup, as I am new to JIRA, and I am reading as much as I can to do it, but yet I feel there something missing and I can't reach to it.
I will really appreciate it if you can assist in this complex setup, until we have a simpler way of doing it, or at least create project templates for (setup / clone) to match users needs and simulates the work environment each one of us has.
Thanks @Curt Holley - it seems like a sensible idea, but I think it would need to be optional... but we really need to understand the cardinality between teams and boards in practice and this is something we're investigating. Do most users have a 1:1 mapping between board and team? Can multiple teams work off a single board? Can teams work from multiple boards? We definitely want to get this right - but it would certainly make configuration much simpler for plans!
Damn fine points @Dave
In my world/experience, most teams would only want their "issue source" configured for one board, but I can think of likely exceptions. So yes! option it would have to be.
Question: Am I right in thinking that a shared team can have more than one "Issue source"? As in, on Plan A shared Team 1 has issue source of Board YZ, but in Plan B shared Team 1 has an issue source of Board XX
If so, then it just means each Plan can only have one Shared team with issue source configuration, but each Shared team (or Board for that matter) can have multiple configurations as long as they point to different Plans.
Yes, you're right that a Shared Team can have plan-specific issues sources (i.e. that the same team can be associated with different issues sources in different plans). In fact the only data that is shared between plans is currently the name and the members and the other data (team type, iteration length, velocity) is scoped to the plan.
My understanding is that the original reason for this (going way back to the early days of Portfolio) is to allow plans to be created for specific work streams... i.e. that a team might contribute to more than one plan and therefore only contribute a certain amount of their overall velocity towards its. I'm not sure that this is necessarily the right approach for the new interface and we're exploring if these use cases could be handled in better ways.
Personally (and this reflects my opinion as a user rather than representing an official position!) is that it would make more sense to have this data shared ... however, this model would obviously break if issue sources were associated with teams outside of the plan (unless it was an optional many-to-many relationship?).
I can see more value in getting visibility of team capacity including work assigned outside of the plan - this is also true of assignees that can belong to multiple teams (which is something we know is also quite common practice).
This is why it is really important for us to understand all the different use cases and ensure that we don't break anything with changes that we make - whilst we want to simplify the configuration, we don't want to prevent people that have more complex use cases.... as ever, it's something of a tricky path to negotiate!
So any feedback that you (or indeed any other community members have!) on this topic is incredibly valuable!
This morning, Atlassian announced the acquisition of ThinkTilt , the maker of ProForma, a no-code/low code form builder with 700+ customers worldwide. ThinkTilt helps IT empower any team in their or...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events