Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-89106

Advanced Roadmaps Capacity Planning should show even distribution of workload

    • 0
    • 2
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      As a user, I would like to be able to see the workload evenly distributed amongst all iterations of a task. 

      Currently, Advanced Roadmaps linearly decreases the estimate for each iteration based on the team capacity and shows "all green" for each iteration, even though the workload overall is too much for the assigned team. Only in the last iteration it shows the actual overload.

      If the estimate was evenly spread amongst the timeline of the task, this would be immediately visible and measures could be taken more effectively, rather than checking on the last iteration of each task. This is eg. how BigPicture handles the capacity planning.

            [JRACLOUD-89106] Advanced Roadmaps Capacity Planning should show even distribution of workload

            Atlassian Update - October 31, 2024

            Hi everyone,

            Thank you for bringing this suggestion to our attention. As explained in our new feature policy, there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritise and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order.

            Unfortunately, as a result of inactivity for an extended period of time, this suggestion didn’t make it to the roadmap and we are closing it.

            While this issue has been closed, our Product Managers continue to look at requests on jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket.

            Thank you again for providing valuable feedback to our team - Jira Cloud Product Management

            Matthew Hunter added a comment - Atlassian Update - October 31, 2024 Hi everyone, Thank you for bringing this suggestion to our attention. As explained in our new feature policy , there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritise and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order. Unfortunately, as a result of inactivity for an extended period of time, this suggestion didn’t make it to the roadmap and we are closing it. While this issue has been closed, our Product Managers continue to look at requests on jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket. Thank you again for providing valuable feedback to our team - Jira Cloud Product Management

            When including regular meeting hours in our resource planning we need the ability to distribute the hours evenly over the complete project duration. Especially when auto-scheduling is used there should be the choice to distribute evenly vs "all meeting hours are pushed to the end".

            Karin.Gleichauf added a comment - When including regular meeting hours in our resource planning we need the ability to distribute the hours evenly over the complete project duration. Especially when auto-scheduling is used there should be the choice to distribute evenly vs "all meeting hours are pushed to the end".

            Agree this is the incorrect choice for the default behaviour. It's relatively easy to simulate "getting the task done really fast" by shortening the duration if workload is allocated evenly across the task.

            If workload is allocated unevenly stretching/shortening a task doesn't actually achieve anything as Jira has decided when the task should have finished based on the available capacity.

            This type of auto-scheduling functionality may be useful for some teams but absolutely should be part of autoscheduling and not the default behaviour.

            Chris Rosser added a comment - Agree this is the incorrect choice for the default behaviour. It's relatively easy to simulate "getting the task done really fast" by shortening the duration if workload is allocated evenly across the task. If workload is allocated unevenly stretching/shortening a task doesn't actually achieve anything as Jira has decided when the task should have finished based on the available capacity. This type of auto-scheduling functionality may be useful for some teams but absolutely should be part of autoscheduling and not the default behaviour.

            JCameron added a comment -

            When trying to migrate from MS Project to Jira Plans, we were really shocked at how bad it was. This was one of the major reasons we saw for it. It is completely unable to understand concepts like "some allocated persistent support over time" and instead thinks "hey did you know the team could actually knock this task out really fast? Also wow your last sprint is going to be TERRIBLE." But it won't tell you where the jam up or hotspots are. We ended up doing our load leveling and time/priority discussions in MS Project since it actually gave us more actionable information, and are now moving it to Plans for visibility.

            We're really hoping that capacity estimation and planning improves. It's not like the bar is high either. Project lets me enter virtual users, set capacity schedules for resources that represent teams, and shows monthly loading histograms. Features that seem pretty "expected" for a planning system. Jira apparently had some of these, but apparently got rid of them sometime around 2018-2019 for some inexplicable reason.

            If we don't see some real changes here, we'll be regularly reevaluating the benefits of Plans. It's SO much more expensive that it really needs to be a one-stop place, which it's not. It's fine for tracking, but nearly useless for planning. Ironic, given its name.

            JCameron added a comment - When trying to migrate from MS Project to Jira Plans, we were really shocked at how bad it was. This was one of the major reasons we saw for it. It is completely unable to understand concepts like "some allocated persistent support over time" and instead thinks "hey did you know the team could actually knock this task out really fast? Also wow your last sprint is going to be TERRIBLE." But it won't tell you where the jam up or hotspots are. We ended up doing our load leveling and time/priority discussions in MS Project since it actually gave us more actionable information, and are now moving it to Plans for visibility. We're really hoping that capacity estimation and planning improves. It's not like the bar is high either. Project lets me enter virtual users, set capacity schedules for resources that represent teams, and shows monthly loading histograms. Features that seem pretty "expected" for a planning system. Jira apparently had some of these, but apparently got rid of them sometime around 2018-2019 for some inexplicable reason. If we don't see some real changes here, we'll be regularly reevaluating the benefits of Plans. It's SO much more expensive that it really needs to be a one-stop place, which it's not. It's fine for tracking, but nearly useless for planning. Ironic, given its name.

            I would just like to say that I also ran into this problem and would love to see it being worked on

            Jano.ANGSTEN added a comment - I would just like to say that I also ran into this problem and would love to see it being worked on

              Unassigned Unassigned
              e5e7037d3158 Fabian Dengel
              Votes:
              9 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: