Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-7038

As a user, I'd like to be still able to drag and drop issues to the 'Epics' or 'Sprints' in case the board's ranking is disabled

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      As a user, I'd like to be still able to drag and drop issues to the 'Epics' or 'Sprints' in case the board's ranking is disabled

            [JSWSERVER-7038] As a user, I'd like to be still able to drag and drop issues to the 'Epics' or 'Sprints' in case the board's ranking is disabled

            Ubisoft added a comment - - edited

            Hi Michael,

            While we do understand that the architecture as it is does limit the options available, it would be a tremendous improvement for us to be able to at the very least, add issues to sprints while ordered by another value than ranking. Given the current reworking of sprints and epics with the latest versions of JA, wouldn't this be far more feasible?

            A a great improvement from that point would be to allow issue sorting in the backlog, not unlike in the issue navigator.

            We'd like to know if it's possible to at least reopen this and keep it on the table.

            Eric

            Ubisoft added a comment - - edited Hi Michael, While we do understand that the architecture as it is does limit the options available, it would be a tremendous improvement for us to be able to at the very least, add issues to sprints while ordered by another value than ranking. Given the current reworking of sprints and epics with the latest versions of JA, wouldn't this be far more feasible? A a great improvement from that point would be to allow issue sorting in the backlog, not unlike in the issue navigator. We'd like to know if it's possible to at least reopen this and keep it on the table. Eric

            Hi Michael,

            agreed that this is not rocket science and that 'the user needs to get out of his/her way to disable ranking", it's not something that's suggested or supported by default.

            At the same time I got there by referring to a Confluence article (don't know where but it must have been under "Atlassian on Demand" documentation - something similar to this), presence of which has the negative effect of busting the users' confidence in believing the 'not ranked' mode is actually supported.

            In my case, I have good reason to disable ranking for my board: we don't want to bother reordering the issues continuously in neither the backlog nor active and inactive sprints. Sorting by issue priority and severity would do the job for us and so i went ahead and modified the filter query as I learned from said article (again, sorry for not being able to link the actual exact article).

            From my point of view, the problem is that disabling ranking kind of leads users into a pitfall. I don't know what you are architecturally able to do with JIRA Agile but if it were possible, a minimal impact help that could be provided to future unlucky user falling in the same dungeon would be a big, fat, red error message warning the user that "Ranking has been disabled. Several features will be disabled as a consequence. Use at your own risk.". Much, much better would be disallowing the user from saving the filter when ranking is disabled.
            From my point of view, you either have a feature and support it or you don't. There is no in-between.

            Ultimately, I think the ability to auto-sort the issues in a board is very important, whether or not it is feasible with the current architecture. It is a significant time saver as most usage patterns deal with a long list of backlog items of which only a handful matter/is important in the short term. Many small or small-ish organizations don't have or don't want or can't afford for whatever reason a dedicated person scrubbing through the issue list and re-prioritizing (read it as 'ranking') the issues regularly.

            I don't need any action to be taken or additional time consuming follow up for you and your team, just wanted to give my opinion and thoughts (as requested by Jason Worley on JST-80999) .

            Best,
            Michele

            Michele Caramello added a comment - Hi Michael, agreed that this is not rocket science and that 'the user needs to get out of his/her way to disable ranking", it's not something that's suggested or supported by default. At the same time I got there by referring to a Confluence article (don't know where but it must have been under "Atlassian on Demand" documentation - something similar to this ), presence of which has the negative effect of busting the users' confidence in believing the 'not ranked' mode is actually supported. In my case, I have good reason to disable ranking for my board: we don't want to bother reordering the issues continuously in neither the backlog nor active and inactive sprints. Sorting by issue priority and severity would do the job for us and so i went ahead and modified the filter query as I learned from said article (again, sorry for not being able to link the actual exact article). From my point of view, the problem is that disabling ranking kind of leads users into a pitfall. I don't know what you are architecturally able to do with JIRA Agile but if it were possible, a minimal impact help that could be provided to future unlucky user falling in the same dungeon would be a big, fat, red error message warning the user that "Ranking has been disabled. Several features will be disabled as a consequence. Use at your own risk.". Much, much better would be disallowing the user from saving the filter when ranking is disabled. From my point of view, you either have a feature and support it or you don't. There is no in-between. Ultimately, I think the ability to auto-sort the issues in a board is very important, whether or not it is feasible with the current architecture. It is a significant time saver as most usage patterns deal with a long list of backlog items of which only a handful matter/is important in the short term. Many small or small-ish organizations don't have or don't want or can't afford for whatever reason a dedicated person scrubbing through the issue list and re-prioritizing (read it as 'ranking') the issues regularly. I don't need any action to be taken or additional time consuming follow up for you and your team, just wanted to give my opinion and thoughts (as requested by Jason Worley on JST-80999) . Best, Michele

            Hi Michelle,

            I would like to suggest to remove the ability to disable Ranking if the methodology is not supported/not working/not intended to be used from Atlassian's point of view.

            Having the ability to do so, although not supported, just mislead users into thinking it is working and can generate not only a humungous waste of time for the customers but also a significant number of support tickets to follow up to for Atlassian.

            JIRA Agile doesn't not explicitly allow users to "disable ranking" as a feature. Our Agile Boards are powered by JIRA's Issue Filters. When you create a board based on projects, we create the Issue Filter for you. Those filters are accessible from JIRA, and if they are changed, then the board's issues will change.

            If you do end up in a state where ranking is not enabled, you can easily correct it from the board's configuration page.

            I hope this helps.

            Michael Tokar added a comment - Hi Michelle, I would like to suggest to remove the ability to disable Ranking if the methodology is not supported/not working/not intended to be used from Atlassian's point of view. Having the ability to do so, although not supported, just mislead users into thinking it is working and can generate not only a humungous waste of time for the customers but also a significant number of support tickets to follow up to for Atlassian. JIRA Agile doesn't not explicitly allow users to "disable ranking" as a feature. Our Agile Boards are powered by JIRA's Issue Filters. When you create a board based on projects, we create the Issue Filter for you. Those filters are accessible from JIRA, and if they are changed, then the board's issues will change. If you do end up in a state where ranking is not enabled, you can easily correct it from the board's configuration page. I hope this helps.

            I would like to suggest to remove the ability to disable Ranking if the methodology is not supported/not working/not intended to be used from Atlassian's point of view.

            Having the ability to do so, although not supported, just mislead users into thinking it is working and can generate not only a humungous waste of time for the customers but also a significant number of support tickets to follow up to for Atlassian.

            Regards,
            Michele

            Michele Caramello added a comment - I would like to suggest to remove the ability to disable Ranking if the methodology is not supported/not working/not intended to be used from Atlassian's point of view. Having the ability to do so, although not supported, just mislead users into thinking it is working and can generate not only a humungous waste of time for the customers but also a significant number of support tickets to follow up to for Atlassian. Regards, Michele

            Many thanks for reporting this issue, however this is not something we are going to add to JIRA Agile at this time.
            Regards,
            JIRA Agile Team

            Michael Tokar added a comment - Many thanks for reporting this issue, however this is not something we are going to add to JIRA Agile at this time. Regards, JIRA Agile Team

              Unassigned Unassigned
              oalsafi OmarA
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: