Done Issues included in Plan despite not selected in Scope

[Tobias]

Hi,

I'm evaluating Jira Portfolio so I'm a newbie regarding this product besides being an experienced Jira administrator.

My use case of Jira Portfolio is to select only specific Epics and their tasks to be included in my plan. So when I define the scope I select the project. We do not use releases so I jump over that one and do not select anything. On the last screen "Confirm what's in scope" I select two Epics and their tasks and click "Done".

I expected to find only the two selected Epics in my plan. But I see a lot of others in state "Done". I already found out, that this is due to the "Include completed issues for 30 days" setting.

From my understanding this filter on completed issues makes sense to further reduce the issues in the selected scope. But it looks like it actually extends the selected scope to all issues done within selected project or board.

I did already some research on this. I find a lot of people wondering why completed issues are not ins scope or are just leaving scope. My issue is vice versa.

Anybody else experiencing this behaviour? Thank you for your advice.

Tobias

[Roi Fine · Accepted solution]

Hey Tobias, 

This issue you are experiencing is caused by an inconsistency in the "confirm what's in scope" and the Plan itself. The plan shows you all issues that were resolved up to 30 days ago as default, while the confirm what's in scope page doesn't show you resolved issues. 

To remove the irrelevant issues you could either remove issues using the bulk actions feature in the roadmap UI - https://confluence.atlassian.com/jiraportfolioserver/editing-multiple-issues-in-bulk-967317189.html

I hope that helps,

Roi

[Tobias]

Dear Roi,

that's it! With "Removing issues from a plan" from the article you provided this is efficiently fixed although a bit annoying.

I can also confirm that this fix lasts for the fixed plan. So you do not have to this again and again for the same plan. After the fix I changed the scope of the plan again to see if the removed issues or others are again included in the plan. This was not the case as long as I did not extend the time period.

So yes, I would also rate this as an inconsistency between the issues shown as selected and the really selected issues.

Thank you, Roi.

Tobias

P.S. Do you know if this is already filed as an issue at Atlassian?

[Roi Fine]

Glad it worked Tobias.

My team has the bug on the radar. We will soon fix it with a redesign for the whole create plan experience.

Cheers,

[Mykenna Cepek]

Removing "Done" items from a plan might work for some situations.

But when a lot of effort has been put into defining issue dependencies, it doesn't work. We don't want to lose those dependencies, we just want the plan to auto-schedule as expected when "Done" issues are encountered.

Some problems we have seen:

• Done issues still consume space in the timeline -- even when their "remaining estimate" is reduced to something like 0.1 hours.
• Clearing the start/end dates for Done issues doesn't help.

It's common for some teams to be able to "work ahead" and complete issues which are later in the plan. That should have an effect of improving (shortening) the overall schedule in some cases, but we don't see that, ever.

I haven't found any documentation that suggests that Status is relevant to the Auto-Schedule algorithm. I think that's an oversight.

I strongly believe that issues with "StatusCategory = Done" should be treated by the Auto-Schedule algorithm as satisfying all dependencies and occupy zero time in the timeline.

Teams should be able to iterate on a Plan. That includes taking the plan as it is today, with updated statuses, revised estimates, changed dependencies, issues added and removed and re-ranked, etc, and then running Auto-Schedule to revise the plan. Ignoring Done issues defeats that effort.