You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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,
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.
P.S. Do you know if this is already filed as an issue at Atlassian?
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:
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.