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.
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.
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?
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.
To see this feature in action check out our recent dependencies demo here: https://www.youtube.com/watch?v=eQu5VsUqyZA Keeping on top of your dependencies is a key part of ensuring project success....
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events