Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


How to make portfolio repect the release order


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.


2 answers

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.

0 votes
Evan Golden
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Mar 16, 2018

Hey Nicolas,

Here is how the release dates work in portfolio:

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.


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,



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?


Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events