Dear all,

I would like to inform you that this issue in the project JPOSERVER is being migrated to the new project JSWSERVER. Your votes and comments will remain unchanged.
Our team at Atlassian will continue to monitor this issue for further updates, so please feel free to share your thoughts or feedback in the comments.

Sincerely,
Aakrity Tibrewal
Jira DC

Hey all,

Thanks for sharing your interest in this functionality.

We've implemented a new Beta dark feature that provides scheduling information in the Portfolio issue detail panel.
If you're on version 2.2.6 or above you'll be able the activate the dark feature with the instructions provided in this PDF (with some documentation guidance).

Schedulingdetails-Beta.pdf

When you click on an issue you'll be able to see all the variables that impact the issue's scheduling, what that likely impact is (not 100% accurate atm), and some suggestions for moving the issue earlier/later.

Since this is still in beta we're very eager to get feedback on it, whether it's helpful and what's missing.

Cheers,

Rhys | PM - Portfolio for JIRA

Your description made me smile as I often spend time doing exactly that.
If not a report, then Atlassian should provide a much better, detailed explanation than this of what scheduling logic is being applied.

Thanks Aaron; we have a call with them today and if I get anything new out of them I'll add it.

During a webinar i got some very good (yet ultimately unsatisfying!) responses from Atlassian (kudos to them for the effort), and i hope they don't mind me quoting their responses.

"The primary variable is the sprint assignment. This is then followed by any dependencies on the issues followed by release assignment. Beyond that the scheduling algorithm goes down the priority list one by one trying to find an appropriate location in your roadmap for each item. See the list of viariables here for more variables: https://confluence.atlassian.com/jiraportfoliocloud/scheduling-behavior-828785428.html "

regarding why some issues seems to be scheduled earlier than i personally felt they should be: "Issue don't need to be part of an epic/initiative. Sometime you may find that there are small gaps of capacity in a sprint that a story can easily fit (whereas the epics work is too great)."

My question: To clarify, will all stories that have no epics, always have a lower rank than stories that do have epics and initiatives?

"No - they are ranked independently on the story level view - so their relationship to each other maintains."

I agree, We have been trying to adopt Portfolio for a year now. I constantly have to have a full blown explanation to answer the simplest question. People stop by my desk and say why is this story light blue here? Good question.

I've also asked Atlassian for these explanations but it takes days to get a reply. I feel like you are in the same boat with digging through the algorithm. Live Plans is a huge improvement over the classic version but is still beyond frustrating and not at all intuitive. I think the functionality is there but what it means is a mystery because there is no documentation or information on what any of it means.

Thanks @Aaron that would be fantastic. It's theoretically useful of them to tell us what the ingredients, are but it's not very helpful without the recipe!

Every time i've asked for comment on this by Atlassian i'm pointed to the article that just states a bunch of dot points of 'things it considers'. Which as you say, isn't much use. I did get some extra intel the other day that i need to dig out and log here - but even with that little bit of info, still doesn't resolve the need to know why something is scheduled where it is.

In a gantt chart you can at least see arrows with the dependencies and it's clear 'why' something is blocked / assigned where it is..

That this logic is happening largely in a black box is a major blocker for us to adopt Portfolio; it's a source of constant confusion for our teams and sends us admins into deep rabbit holes we really don't have time for. The documentation tells you the criteria JP uses, but it's basically useless when you're trying to figure out why a given issue was scheduled a certain way.

Yes, this feature or something like it would be extremely useful.

Without control over the schedule, sometimes we're forced to abandon JIRA Portfolio since we can't make it reflect reality.  Controlling the schedule can be very difficult because the process of calculating the schedule is completely opaque.  A project manager might waste hours, or even days, trying to figure out why JIRA Portfolio insists on ranking top-priority tasks last on the schedule, or other quirks.  Feedback of some kind about WHY an issue was scheduled the way that it was could make this into a much more useful and reliable planning tool.

See also: https://answers.atlassian.com/questions/39579938/answers/46686009/comments/46795233

I found this, that takes a really brief stab at it - but its the kind of report explanation i'd like.

"So, how does Portfolio actually come up with the schedule?

I’m glad you asked! The basics: Priority order + Estimates + Team capacity = Schedule. (In priority order, get the work items done as fast as possible). Then, there’s releases: you want feature B in version 1.0, feature C in 1.5, and feature A wherever it fits in? In that case, the best option is to do B first, then C, and then A as it is not a “must-have”. Unless there is – beware – a dependency! Say B actually requires A to be done first. Now of course the only logical order is A, then B, then C. Easy! Unless there is an earliest start date somewhere? Or someone is on vacation and there is less capacity? Or feature B requires a specific skill to get it done, and only certain people on the team can do it? All of these constraints factor into the schedule automatically, so you don’t have to think through it by hand."

I'm aware of the page that attempts to explain the order of operations

https://confluence.atlassian.com/jiraportfoliocloud/scheduling-behavior-828785428.html

which is an interesting insight, but it's far too vague.