Advanced Roadmaps (Cloud) has shifted Sprints out of order

[kevin.kowitski]

I am pulling in sprints that are aligned to the same schedule and naming convention across different projects and boards.  Aligning a single board to a single shared team. The system is successfully recognizing that the sprints of the same name from the different boards are intended to be executed in the same time period.  However, the plan is shifting the sprints that were created on the board backlogs out of order, and then issuing a warning that they do not have the same dates. 

I have tried to re-define the sprints, but the tool started doing strange things in the plan like creating duplicate sprints. Then instead of re-defining / renaming sprints, I deleted and started over building out the sprints.  Still the same problem. 

I have included attachments that show two different boards for two different teams. These teams have the same active sprint with the same start and end date.  Both of these boards/teams have the same sprints built out in the same order in their backlogs. However, the plan has shifted the sprints out of order. 

[Dave]

Just catching up with this thread as I got notified by the recent post from @Olga Plisko ...

To give some context around this it's important to understand that sprints are not tied to any specific board. If an issue on a board is assigned to a sprint then that sprint will appear on the board (so sprints can actually appear in multiple boards).

On more recent versions of Server / Data Center it is possible to configure the start and end dates of future sprints (this capability isn't available on Cloud yet) but typically only active and completed sprints have start and end dates.

When you include a board as an issue source in an Advanced Roadmaps plan it will bring in all the sprints that are associated with that board. Active and completed sprints will be rendered on the timeline using the dates that they have, but all future and projected sprints will be rendered based on their order on the board and the iteration length configured for the issue source.

A future sprint is any sprint that exists on the board that is neither completed nor started and a projected sprint is a sprint that is expected to be created based on the iteration length.

Due to the absence of guaranteed start and end dates on a sprint this can result in sprints appearing in unexpected positions on the timeline. This often occurs when an issue is assigned to a team that is not associated with the issue source from which the sprint assigned to the issue is derived.

You can also get duplicate future sprints appearing (sometimes with different lengths) in this case too - especially if the sprint is assigned to issues for different teams with different sprint lengths.

We'd typically recommend that you try to organise your work so that each team has it's own dedicated board (you can do this by sharing the team and using it in the JQL filter used for the board source and then using that board as an issue source that you associate with the team).

We're actually investigating making this much simpler - ideally, the iteration length and team associated with the issue source should be configured on the issue source itself. The way that it works right now is a result of the Advanced Roadmaps previously being a 3rd party application.

Hopefully this explains some of the behaviour that is happening. Please let me know if anyone needs any further clarifications or if it feels like their is a bug that needs addressing (although in the case of a bug it might be more efficient to log a support case).

Regards,

Dave

[Motti Friedman]

Hi Dave,

In our plan (I work with Olga), an active sprint appears on the plan with a different end date than on the board. The board is a simple filter of label in a single project.

After the altered sprint,  we get a projected sprint that is followed by actual future sprints. It's a mess.

I would exepct projected sprints to only appear after the existing future sprints. Also, it would be great to be able to assign dates to the future sprints and fix the automated mistakes.

I do have two teams defined in the plan but they are defined by assignee and all are part of the same board. 

Appreciate your insight 

Thanks

Motti

[Dave]

Thanks for getting back to me with those extra details @Motti Friedman, that definitely doesn't sound like the expected behaviour. I would definitely recommend raising a support request to look into this as it is likely to yield a faster outcome, however if you want to share some screenshots of what you're seeing then that would be good, for example:

• the active sprint on the backlog
• the sprint on the plan (ideally with the sprint flyout displayed)
• the configuration for the team associated with the board that the sprint appears on

Projected sprints definitely shouldn't appear before future sprints though. You should definitely ensure that the issues are assigned to the team associated with the sprint. Are you grouping by team or sprint to see the sprints on the timeline?

Regards,

Dave

[Motti Friedman]

Thanks for the quick response, Dave. 

Here are a few screenshots: the plan showing projected "Sprint 5" added before future "Q1-21:Sprint6". The dates on "Q1-21:Sprint5" that are different in plan than in backlog. 

We'll open a support ticket as well. 

Thanks

Motti

[Dave]

Hi @Motti Friedman

Thanks for sharing those screenshots - the first thing I've realised is that you're referring to the old "Live Plans" interface rather than the newer interface. Out of interest are you on Cloud or Server? 

We've recently deprecated the Live Plans interface and this will no longer be available on Cloud after July of this year (if you're on Server then you have more control over how long you have access to it depending upon when you choose to upgrade).

I'm not as familiar with the implementation of the Live Plans interface (having joined Atlassian as we were building the newer interface) so I'm not able to say for certain if this is a known issue (or even working as expected).

Regards,

Dave

[Motti Friedman]

Hi Dave,

We are on server and I moved the plan to the "old view" as it seemed to have more configuration options and I was hoping to be able to solve this problem by config. 

The same problem does also appear witht he new interface and in fact, the frist plan I built was using the new interface. 

The new interface is still lacking in some configuration flexibility and also in the way releases appear on the timeline, viewiung the sprints on the timeline, etc. 

Thanks,

Motti

[Dave]

So is the sprint order shown exactly the same when you switch to the new interface? How many teams are in the plan? If more than one, are they associated with multiple boards? It looks like you have releases spanning those sprints? Do you have story level issues assigned to the release? I'm wondering if that's causing the grouping of the sprints like that (but then I wouldn't expect them to show like that in the new interface). As I said, I'm not as familiar with exactly how the Live Plans interface, but I'll follow up with some of my team tomorrow (it's out of hours in Sydney now).

Regards,

Dave

[Motti Friedman]

I just found that in the Teams configuration it is possible to select the relevant sprints and tehre I was able to uncheck this "sprint5" that was added. It then brings a new "sprint5" AFTER my actual future sprints as woul dbe expected. 

Still strange that I had to go through that, but at least we havea  valid workaround now :)

I also tried to create the same plan using the new interface. But with the new interface I could not find how to present the sprints on the timeline view - is there a way to do that? 

[Dave]

To show sprints on the timeline you need to do the following:

• Ensure that you have a team associated with the board that the sprints comes from
• Ensure that you issues assigned to the team
• Use the "View settings" menu to group by team or sprint (and ensure you have the "Show capacity on timeline" checked.

You should see something like this:

The sprint also shows team capacity bars to help ensure that your sprints are not overbooked.

Regards,

Dave

[Motti Friedman]

I think I broke Jira :(

1. In the new view, it still insists on defining a projected sprint5 in between my existing sprint6 and sprint7 and the option I found in teh legacy view to remove it, does not exist in the new view. 

2. Items are not assigned to teams when I "auto-schedule" no matter what I try (I have two teams from teh same baord defined by assignees).  Only items that I manuually assign to a team goes to the grouping. 

3. When I push "Accept changes" after auto-schedule is done, it does nothing. I can only cancel and discard the changes. 

4. My Sprint6 is now active and the dates are Mar-17 to 30 but Roadmap still insists to end the sprint on Mar-29 instead (on both legacy and the new view)

[Dave]

When you click on that "View sprint in Jira" link (shown in the last screenshot) it should take you the active sprint, from there click on the "Backlog" and it should show you all the sprints... can you confirm that "Sprint 5" is not showing immediately after the active sprint?

If it isn't then I'd definitely suggest raising an issue with support for us to dig into this further: https://support.atlassian.com/contact/

Regards,

Dave

[Olga Plisko]

The same problem happens in our plans. The sprint dates in the plan not the same as original sprint dates. The plan's sprints dates are shifted and plan has created additional (dummy) sprints. We use freshest version of Advanced Roadmaps in the JIRA Server 8.5 (enterprise) version.

Could someone from Atllasian team to answer and explain this behavior? 

[Courtney M. Schkurko]

Did you ever get an answer to this? The same thing is happening to me. I have multiple teams on a train sharing common sprints. The tool cannot recognize the order even though when I look at the backlog, the sprints are in the correct order by rank

[Karl Hamilton]

Sometimes when my plans are created, duplicate sprints are created until I assign the team using bulk update but I don’t know why.

i think it could be a problem with board filters In jira or issues having attributes making them appear on duplicate boards in jira before import to plans in advanced roadmaps.

does everyone have to assign teams In advanced portfolio before Sprint capacity icons appear?

[Richard Cross]

Aha - thank you for solving that particular issue for me!

:-)

[Karl Hamilton]

No problem Richard! :-)