Hi stefan.hennig,

as akavelar just mentioned, it could be a different problem.
Can you confirm that the fixVersion field was already enabled for your issues at the time they have been created? If not, it could be that the index was just outdated, so it might be necessary triggering a re-indexing after adding the fixVersion field.

Probably you could try to remove your custom "Later" release from an issue again and see if it still shows up in your Portfolio Plan.

Cheers,
Paul
Portfolio for JIRA Development

Hi stefan.hennig,

thanks for your reply and the additional information. Just to clarify - you have the fixVersion field enabled on for all issue types as well? Were the issues not showing up all of the same type? Where they all coming from the same project?

It sounds like you might be facing a different issue than this one, could you raise a separate support ticket here so we can follow up on it and get to the bottom of it?

Thanks,
Best regards,
Albert Kavelar | Portfolio for JIRA Development

Hi!

I was faced with a quite similar behavior. We are using the fixVersion field, it is enabled for all our projects, but some issues without a concrete version assigned were not shown in the Live Plans. The curious part is, that other issues without a fixVersion assigned are shown.

I was able to fix that behavior by assigning a concrete version to all issues. Those issues without a fixed schedule got a "Later" release. Only with this workaround, I was able to see all issues in the Live Plan.

Cheers,
Stefan

This one caught us too. Many of our projects don't bother with versions, especially when we're using them for non-software projects.

Hi thagen,

thanks for the update. Too bad we no longer have the plan where the problem occurred. Anyway, we are happy to help you out with the other problems you have and suggest to file new tickets here since they are probably unrelated to the original issue you reported on the hidden fix version field.

Thanks,
Best regards,
Albert

Hi, Martin and Albert: Sorry for the delay. Unfortunately, the product owner who was testing this behavior has reverted to the traditional plan and deleted her Live plan, so I can't confirm. However, it's safe to say that we were using neither releases nor subtasks. Instead, I'd like to loop in one of our other product owners, Jon Hill, who has some related scheduling questions and suggestions – perhaps best addressed in new issue(s)? Thanks.

Hi thagen,

any updates on the questions msturm@atlassian.com asked in his last comment? Did you find the time to look into this?

Best regards,
Albert Kavelar | Portfolio for JIRA Development

Hi thagen,

thanks for providing the additional information. There is nothing too suspicious though.. I also do not think it's related to the issue in the group, because there was only some confusion about how we filtered the solution on different hierarchy levels.

Can you please verify that this plan doesn't use any releases? Having issues assigned to releases with dynamic end date might change the priority of this issue because we try to schedule it as soon as possible in order to minimize the dynamic release date.
The other possibility would be that this is another case of our scheduling with subtasks problem: https://jira.atlassian.com/browse/JPO-1323
I do not see any subtasks in the table though, right?

Thanks, Martin

Hi Martin,

We are on Cloud: 1.12.2.
We are using Rank: ORDER BY Rank ASC
We are only using one board for the project.
The order of the issues in the Scope table does not change on refresh.

If you are unable to reproduce, then we can work around this for now. In fact, I think our product owner has tried starting over with a new plan, so I'm not sure if this is still impacting us. I also thought this might relate to the same issue: https://www.linkedin.com/groups/7018171/7018171-6106451939954880515

Thanks for the reply,
Tim

Hello thagen,

I am still having trouble to reproduce the ranking bug.
Can you please tell me which version you are using of Portfolio you are using? If it is one of the betas (1.11.x) please update Portfolio.
If you are already on a recent version I'd like to know if you are using some custom field other than the default rank field used by Agile (you can check that by clicking Board - Configure in Agile which shows you the board query)?
Are the different boards in your project ranked by different fields?
And does the order of the issues within the table also change on refresh?

Hello thagen,

we are still looking into the scheduling discrepancy you mentioned, we'll update you as soon as we find out more.

Best regards,
Albert Kavelar | Portfolio for JIRA Development

Any ideas on this scheduling discrepancy, or should I open a new ticket?

Martin, thanks for the reply. Our Dependency Configuration is disabled for now, so that shouldn't be the culprit. Our version is Portfolio for JIRA v1.12.1-OD-002-D20160209T234342. Is that the latest?

By the way, the reason we removed the blocking dependency was because it would force the blocked issue into the next sprint, even if we planned to address both issues in the same sprint.

Hi thagen,
So no, there shouldn't be any problems if you are not having releases, it's just that we need the field visible.
You can however create Releases within Portfolio if you want to enable release planning just like in the old plans.

Regarding your questions about scheduling: Basically the scheduling should work pretty much the same as before. The priority and sprints are directly taken from Agile. This means you'd have to create sprints on your Agile board and add issues to it for now. In later versions we might also allow creating sprints in Portfolio and do the assignment directly as a scenario (just like changing an estimate for example).
The schedule you got looks a bit strange indeed. First question here is, are you on the latest version? One of our private betas we gave out had a bug in the sorting of the issues when calculating the schedule. If you have the latest version: Are there any issue links involved that are used as dependencies in Portfolio? If you didn't change the Dependency Configuration this should only be" blocks" and "is blocked by". Please note that these dependencies are also inherited from the parent epic.

Cheers, Martin

Thanks, Martin. Are there additional consequences of our not using Releases? Now that we have enabled that field and imported our issues into a Live Plan, we're having trouble figuring out how issues are being assigned to sprints. This can be done manually in a normal plan. What's the scheduling formula for Live Plans, and is it documented anywhere? You can see from this screenshot that there appears to be no rhyme or reason to where the top issues show up over the next several sprints, nor can we force it. P.S. This screenshot was taken after clicking "Recalculate," which seems to shuffle the sprint assignments slightly each time, even though no other changes have been made.

Hi thagen,
it will probably be a hard requirement for Portfolio Live plans to have the fix version field enabled.
Sorry for the inconvenience.

Cheers, Martin

Martin, thanks for the reply. It would be possible to enable it, but not preferable, since our team does not use Fix Version/s, and it would only clutter up our JIRA interface. Are you suggesting this as a permanent solution or a temporary workaround?

Hi thagen,

sorry for not coming back at you earlier.
The reason for this is that this issue escalated because there are a number of integration points where we rely on this field and if it is hidden in JIRA, Portfolio can't access it either.
Would it be an option for you to enable it in the field config?

Cheers, Martin

I heard that this was being added to the current development sprint a couple of weeks ago. Any update? We have at least one team that is eager to take advantage of Live Plans, but their field config excludes Fix Version/s.