How to make portfolio repect the release order

[Nicolas Rimmer]

We are just starting out with portfolio so this may be a basic question. We have noticed that the calculated plan can make a different order of the releases to that defined on the source board / project.

This is an understandable behaviour in that it is utilising the capacity as much as possible and therefore if something can be done first it is. I can see that would suite some users of portfolio. In our environment (chip design) it is not possible to validate the chip until it has been manufactured so there is an inherent order to the releases that cannot be broken.

We want to maximise our capacity to get the best schedule so do not want to ban work on the next release until the previous release is finished. Banning work on the next release until the previous is completed leads to a capacity utilisation "saw tooth" and a very long schedule.

The work around we have found is to make an issue for each release (we call that a milestone) and chain them together with blocking relationships. We then block the milestone with every issue that is for that release. Portfolio then schedules as expected maximising the capacity use but never changing the order of the releases. [SEE PICTURE AT THE END: Red = blocking relationship, black = allocation to a release]

My basic question is have we missed something? Is there an easier way to do this?

It is a pain to maintain all these blocking relationships (though there are other good reasons to do it). We have written a quick python script to do it but people forget to run the script before clicking the "calculate" button in portfolio.

I wonder if there should be a scheduling option for Portfolio called something like "Respect source release order" so that there is no need maintain all these blocking relationships to get the desired behaviour in this circumstance.

[Nicolas Rimmer]

Please note that what I posted above in my question is only guaranteed to work if the Dependent Story Constrain in the scheduling options is set to on.

We have discovered that if the Dependent Story Constraint is off and there is a large place holder story, with an assignee on the team in portfolio then the blocked Milestone is scheduled when the place holder task starts and not when it finishes. So it appears that the blocking dependency is "start to start" not "end to start" as we expected.

[Evan Golden]

Hey Nicolas,

Here is how the release dates work in portfolio:

https://confluence.atlassian.com/jiraportfoliocloud/configuring-release-dates-828785321.html

Release date is set in one of the following ways:

1. Fixed Date

2. Dynamic release date

Why not use epics with their own release dates?  Are you currently using epics in another way, because I do not see them in your diagram.

[Nicolas Rimmer]

Evan,

Thanks for replying, it is really appreciated.

In the first round of planning we don't want to set any dates at all (at story, epic, release level). We just want to work out the earliest possible release dates for the versions whilst keeping the versions in order. This is a front loaded plan (using our terminology from MS-Project days) using up the all the capacity available to get the earliest date.... then starts the discussion with business/customer.

I have seen that I can set the release dates of the releases as you suggest and perhaps that will be appropriate when we have made an external commitment on the date to the customer. 

We are still learning about how to use epics effectively. Our current thinking is that they are a collection of stories that represent something the customer is interested in. For now we are not putting story point estimates on epics but only on the issues that are part of the epic. I guess we are almost treating them like a mathematical set of issues. We are still figuring out how to put place holder "epics" in the backlog.... so the medium / long range planning.

Kind regards,

Nick

[Kai Franke]

Nick,

It feels good to read I am not the only one struggling with this problem. I also considered writing a python script to add the blocking relationships but it just seems like a not so nice solution.

I also considered Evan's solution using epics. Currently we use epics to group features and it is possible that two epics are within one release. Since epics do not support hierarchy it would not allow me to group all issues within a release using an epic and I do not really want to use an initiative for it either.

Which solution did you end up using?

Kai