Why are sprints missing from my plan when adding new issue sources?

[Rob Horan]

Assume I am using a plan with two boards as issue sources.  When I created the plan I was able to associate the issue sources with teams. 

I am able to associate teams with issues and see capacity on the timeline. Yay!

Now I add a third board to the plan.  Advanced Roadmaps does not allow me to associate a team with the issue source.

As a result, even if I associate every issue with a team, the sprint information does not appear on the timeline, and capacity planning fails. 

Two questions:

1. Why isn't AR showing capacity when sprint values and teams are associated with the issues?
2. How can I associate a team with an issue source added after a plan has been created?  How do I fix this?

[Curt Holley]

Hi @Rob Horan

Go to the roadmap views and select Teams. click the the more options (the 3 dots) on the team required and select Edit. From there you should be able to add or edit the issue source for the team.

[Rob Horan]

Thanks @Curt Holley  - this helps. 

One thing I actually don't understand is why using boards is necessary for sprints/capacity.

If issues have sprint values and teams are associated with those issues, isn't that enough?

If we ever meet in person I owe you a few pints!

[Curt Holley]

Interesting point Rob. Not sure I have an answer.......
Maybe to help AR be able to sequence up all the sprints from a board and present it on the timeline, based on whichever team it is configured for? 
and!!! if you didn't associate a board with a team, I'm not sure how setting the capacity could be done.

[Rob Horan]

To address your comment: if you didn't associate a board with a team, I'm not sure how setting the capacity could be done.

What's a board other than a visual representation of issues based on a query?  In that sense, what makes it different from any other issue source?

In the end, shouldn't the value of team in an issue be the driver for capacity?

What if a board is associated with Team A and all the issues in that board have Team B as the Team value?

[Curt Holley]

I believe Atlassian are:

• Aligning with Scrum thinking of "Capacity is measured by what is in the timebox known as a Sprint" and by associating with a board you confirm the teams core work/set of timeboxes.
• Doing a lot of work around the concept of "Team" in Jira, as AR has introduced...more confusion. Plus, the team field really does need to be sortable, usable without being in the advanced issue search etc. So by Christmas who knows what changes and new powers the team field will have

For my money, the association of a team with a board works just fine. Perhaps not that intuitive, but once you know that is how and where it is done. All good.

[Rob Horan]

But what if 30 teams are associated with one board?  :)

(30 is a high number but what if it's 2 or more?)

[Curt Holley]

Besides that being a bad idea, I can only imagine it would only pull the content pertaining to the team you associated the board with.

From an AR capacity planning prospective, what it is kinda dictating is; one team associated with a board that will represent their capacity for planning purposes.

How that board is filtered and whether any of that teams content is visible on other boards is entirely flexible.

I've always found, play to Jira's strengths, follow its lead (on how it wants you to do certain things) and it actually helps you/teams be more Agile (it can be a good teacher). But try and hack it and.....you may well achieve the intended outcome (it's a very flexible tool), but is that outcome optimal is what I find myself asking.

[Rob Horan]

I'm not looking to hack or find edge cases. I have a legitimate scenario I'm trying to make AR work for and it's being difficult, to say the least.  It's extremely rigid and forces users to work the way it wants people to work.  I thought the whole point of Jira was its ability to create workflows that mimic any business process.  What happened to that? 

Anyway, my point was that multiple teams can contribute to a high-level objective.  Assume for a moment you have a board that represents that high-level objective, and that several teams that contribute work towards that objective.  Advanced Roadmaps only lets you associate the board with ONE of those teams.  Why? 

Moreover, what's the point of associating a team with a data source when the team field needs to be filled in separately?  :) Isn't the whole point of the team field to associate a team with the work?

But OK, let's say one was to follow Jira's lead.... what is that lead?  Are there guidelines?  What is the big picture here?  How SHOULD things be done?  I'm not asking that rhetorically, I'd really like to know.  I'm still waiting for an answer here:

https://community.atlassian.com/t5/Advanced-Roadmaps-questions/Is-there-something-like-Advanced-Roadmaps-for-Dummies-out-there/qaq-p/1961714

[Curt Holley]

Have you watched this? How Atlassian Uses Advanced Roadmaps - YouTube

Regarding:

"Anyway, my point was that multiple teams can contribute to a high-level objective.  Assume for a moment you have a board that represents that high-level objective, and that several teams that contribute work towards that objective.  Advanced Roadmaps only lets you associate the board with ONE of those teams.  Why? "

I would recommend setting the Objective (issue type I presume) higher in the hierarchy (that a Jira Epic) and link up to them via the "Parent Link" field.  Have them on a board or whole separate Project and don't associate them with any team, but have the Epics/stories etc assigned out to the various teams.

One objective, with various Epics and subsequent standard issue types assigned as far and wide as required to achieve the value of the Objective. 

Bonus tip; You can then use issue in portfolioChildIssuesOf("Objective Key here") to filter on everything hieratically linked to the Objective key you enter. 

[Rob Horan]

I'll give that a watch, thanks. And @Curt Holley, if I haven't said it before, I genuinely appreciate the time you've taken to respond in this thread. I have a much better understanding of the tool because of your responses. Thank you.

I think many organizations will need to have dedicated boards for their teams and then use multiple boards as data sources when creating plans. I can't find any way around this, and it seems like a design flaw.

If it is not a flaw, I would like to see why there needs to be a 1:1 association between data source and team AND a Team value in issues for capacity planning to work. I don't know what's going to happen when multiple teams work on a single Epic.  Will that even work? If capacity planning requires association with a data source, why is the team value needed? If the team value is populated, why is the association with the data source needed? 

I'm assuming the answers are in the documentation somewhere, but the documentation does not focus on the high-level understanding.

[Curt Holley]

Yes, multiple teams can work on a single epic. If you enable "Roll-up/other" in the view settings of the plan you even get an overview of all teams involved. see mini example below.

Here we have Abel Tasman with a story assigned, but Kepler are assigned to the Epic.  Abel Tasman is rolled up and visible on the team field (in the Plan). You can also filter on either team to slice the work down into the parts assigned to them. 

Dedicated boards for teams and multiple data sources for Plans is how AR is designed to work. Then by associating the shared team with their board, Boom!! you have Sprints on the Plan and team level capacity planning.
One thing I have thought of is, by associating a shared team with a Board per Plan, if that team have work on multiple boards across a number of projects, each plan can be set up to point at the relevant issue source for the shared team/s. In this way, the capacity can be broken down into these relevant chunks, but also scaled up to show their total capacity on a "master" plan, based on an issue source/s that contained all their work.
This would take a bit of set-up and I'm not encouraging such "spread thin" behavior for the poor team, but it can all be achieved in AR.