-
Suggestion
-
Resolution: Low Engagement
-
None
-
1
-
5
-
Ideally - a toggle for each type of calculation to enable/disable variables to be included/excluded from the calculation
As a plan owner, I would like to be able to toggle on/off certain calculations so that I have better control over my plan when I want to. For example, while sometimes it may be useful for the tool to predict my sprints, the use case is often that the sprint has been determined and should be input by the scrum master or product owner. Having it calculate something and fill in the field can be confusing for users and lead to items not truly being scheduled because the plan owner didn't explicitly choose a sprint for the item and thus the sprint was only reflected in the Plan, not on the agile boards.
- is duplicated by
-
- Closed
- is related to
-
- Closed
- links to
- mentioned in
-
Page Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSWSERVER-24891] Allow for finer control of schedule calculation
Dear all,
I would like to inform you that this issue in the project JPOSERVER is being migrated to the new project JSWSERVER. Your votes and comments will remain unchanged.
Our team at Atlassian will continue to monitor this issue for further updates, so please feel free to share your thoughts or feedback in the comments.
Sincerely,
Aakrity Tibrewal
Jira DC
Bryan Kayne
added a comment - We run into confusion with the blue calculated fields, would be better to give users the option to not have any calculations or, use calculations.
Bryan Kayne
added a comment - We run into confusion with the blue calculated fields, would be better to give users the option to not have any calculations or, use calculations. Following a discussion on service desk ticket JPO-2551, I've been asked if I can comment here to describe my use case and why I'd like to see this feature implemented. I've been trialling Portfolio and I've really got an issue with the fact that it is prioritising rank (i.e. order of backlog items) over planned release dates (fix versions).
I'm trying to use Portfolio to do some forward planning and tell me the art of the possible regarding release dates, and as backlog items are not yet scheduled for work, I don't want to have to comb through many tickets to get them in an artificial order so that the Portfolio scheduler will calculate correctly. If I don't do this, items which are set for a later release are scheduled into the work allocation of an earlier release and causing the earlier release to go late. The support desk has suggested a few workarounds which don't fit my needs, as I would end up with resources with gaps in their work.
A full description of the problem (with reproduce scenarios) can be found in JPO-2551, so I won't repeat here, but will try to summarise a reproduce scenario:
I’ve created a very simple setup:
- A scrum board with 2 projects;
- 3 virtual resources
- 2 cross product releases:
- “Integration” – start as soon as possible, fixed release of 28th Oct;
- “First Product” – start as soon as possible, fixed release of 22nd Dec.
I have a bunch of tasks. One such task, “SSP3” is assigned to the “First Product” release but has been scheduled before tasks which are assigned to the “Integration” release, and as a result has made the “Integration” release go late. This occurs because “SSP3” has a higher ranking in the backlog.
One way to make this work is for the “First Product” release to have a start date relating to the previous “Integration” release. In practice this does not work because developers who finish early on the “Integration” release could potentially start work on the “First Product” release tickets, but the scheduler leaves them with nothing to do until after the “Integration” release.
Deleted Account (Inactive)
added a comment - Would like to see more use cases on this. Portfolio relies on the size and rank to determine which sprint it best fits in, and that's if the JIRA doesn't have a fix version. Would like to have the ability to select a future sprint versus a fix version for planning. Would also be nice for it to not predict a sprint just because a JIRA has a default estimate.
Deleted Account (Inactive)
added a comment - Would like to see more use cases on this. Portfolio relies on the size and rank to determine which sprint it best fits in, and that's if the JIRA doesn't have a fix version. Would like to have the ability to select a future sprint versus a fix version for planning. Would also be nice for it to not predict a sprint just because a JIRA has a default estimate.
Hello,
Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself.
Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap.
Please note the comments on this thread are not being monitored.
You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here.
To learn more about our recent investments in Jira Data Center, please check our public roadmap and our dashboards, which contain recently resolved issues, current work, and future plans.
Kind regards,
Jira Data Center