nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why is my initiative end date earlier than the epics it contains?

Michael Goertz

I recently started using Portfolio Server (2.10) for my project planning and have run into an issue where the initiative end date is earlier than the epics it contains. There doesn't seem to be enough visibility in the scheduling factors to indicate what caused this situation.

Has anyone else experienced this situation and what did you do to resolve it?

Please let me know if there is other information I can provide to diagnose the issue.

This is really limiting my ability to use Portfolio for project planning, so I hope to figure out what is going on soon.

Comments

Amanda {Praecipio}

Hi, Michael!

Are you using estimates and is all your work estimated in the Plan? Or do you have Default Estimates set?

If the Epics are tagged to a Release, but contain no estimates, the timeline for the Epics is extended to the End Date of the Release. The Initiative may be calculating its end date based on the estimates of the Epics, but not the specific roll-up of the Release End Dates on the Epics.

We see the same thing in our Marketing Plan: The Initiatives are scheduled based on the total estimate (which is very small). The Epics themselves schedule their timelines based on the Release End Date itself (because they are unestimated).

Either tag the Initiative to the desired Release or add estimates and that should make things schedule "correctly."

Michael Goertz

Hi Amanda,

I am using estimates for all epics and stories. I have enabled default estimates for epics/stories that do not have an estimate assigned.

All issues have an assigned release, and those releases do have a dynamic release date. Initiatives are in a separate JIRA project that does not contain the release milestones that are in the project that contains the epics/stories. Initiatives are designed to span releases and thus cannot/should not be assigned a single release milestone. Rather the should inherit the milestones from the child epics/stories.

It seems that Portfolio is estimating the epic end date correctly based on the time estimate, but for some reason the initiative doesn't seem to reflect that there a epics that complete past the scheduled end date of the initiative.

It seems that the only way to get the scheduling of the initiative to work "correctly" is to remove the release from all epics and stories. Once I do this, the initiative scheduled end date is the same at the latest epic. Unfortunately, this process doesn't work my workflow right now, since we use the fix version to set a target release that the development and validation teams use to plan their work. We might be able to alter our workflow in the future, but for the time being, I need to be able to assign the release.

It seems odd to me that scheduling doesn't work properly when issues are assigned releases especially when those releases have a dynamic release date. If I cannot manually assign the release milestone, I cannot assess when that release will be complete based on the portfolio schedule and the manual grouping of work to be done.

Thank you for your guidance, since you have pointed me in the right direction. Unfortunately, I still don't know enough about the best practices for using Portfolio such that I can get meaningful dates from the scheduler.