Can I use Portfolio for JIRA without releases?

[Clayton Taylor]

I work on a team that uses Kanban methodologies and is moving from continuous integration towards continuous deployment. This means that releases are not predefined like sprints in Scrum methodologies.

Portfolio for JIRA has many useful features, but it appears that they are all reliant on releases being assigned to issues. Is this the case? If so, is there any planned support for continuous deployment teams?

[Clayton Taylor]

Based on the documentation provided, it would seem that Portfolio for JIRA does not have any smarts in the way of calculating a projected time based on time that has already been spent working on issues. It appears that all time based calculations require that a user enters estimates on each issue, releases assigned to each issue, target dates assigned to each issue or a combination of the three, making Portfolio for JIRA a tool for visualizing manually entered values and not one that helps to project time taken like I would have hoped.

I appreciate the quick response, but it seems that we will need to look elsewhere for a planning tool to support our team transitioning to a continuous delivery methodology.

[Earl McCutcheon]

Hello Clayton,

With Portfolio for Jira, if you have a release scheduled, and you have an issue scheduled to complete before, portfolio is going to add that issue to the release.  Please see "Using the later release" for more details on the release calculation.

If you do not want an issue to be calculated into a releases use Dynamic Release dates, and manually assign a fix version on issue completion.

Regards,
Earl

[Clayton Taylor]

Hi Earl,

Thanks for the reply. Based on the link you provided, it appears that the reason the later release is not working the way I expected is because we also do not estimate stories/tasks going through the pipeline.

Am I right in assuming that we need either created and assigned releases and/or estimates on issues in order for Portfolio for JIRA to display the issues as expected?

Thanks,
Clayton

[Earl McCutcheon]

Hi Clayton,

Yes that is correct, there needs to be a time based data point in place for the algorithm to make time based calculations to be able to put the issue on the schedule within that allotted timeframe.

The document Scheduling behavior goes over the data point scheduling factors in more detail.

Regards,
Earl

[Clayton Taylor]

Ok, I was hoping there was a way to do it based on statuses and actual time since we don't predefine releases or estimates.

With the dynamic release date, is there a way to pull based on specific criteria? We use the "Release" feature in JIRA Kanban boards to set the Fix Version when issues go to production, so releases are created at the end of an issue's lifecycle.

Thanks,
Clayton