• 2
    • 1
    • 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.

      At the moment JIRA is the ultimate tool for issue tracking and Agile development. The only thing that is missing (in my opinion) is the ability to work with velocity. I suggested this feature at the Atlassian stand at Devoxx and the man who was listening to my suggestion seemed to agree on the idea. He suggested me to add a feature request in JIRA which is the cause of this issue.

      GreenHopper has build in functionality for Story Points. Velocity integration in GreenHopper would be the final feature to make JIRA complete for Agile development. Let me explain how I see a possible implementation of working with velocity. This is only my vision and improvements to this possible implementation are always welcome. My possible implementation will reflect the way of working at my company, but I think that it is applicable to all Agile companies. Please note that screenshots given here are mockups, so no implementation exists at the moment. The mockups are given in a hope to making my proposition clearer.

      Every version in JIRA represents a sprint. Each sprint is linked to a certain velocity for that sprint. A possible implementation can be found in screenshot 1. Let me explain.
      When the first version (or sprint) is created, there is no velocity yet. The (estimated) price for the project is calculated on a chosen velocity, based on previous experience. Therefore, it is possible to specify a velocity in the textbox.
      However, when following sprints are created, the velocity can be calculated using the hours worked and the amount of story points that are resolved. So when a new version is created (sprint 2), you will select sprint 1 as the "Schedule" version in JIRA. When selecting the checkbox next to the velocity textbox, it will discard any input into that textbox and it will calculate the velocity of the previous sprint and use that velocity as the velocity for the newly created version. It is always possible to override the calculated velocity by unchecking the checkbox and entering a custom value.
      An extra possible admin feature would be the possibility to adjust the formula used for calculating the velocity based on the previous ("scheduled") version. This could be done by introducing placeholders in the formula textfield like

      {story.points}

      ,

      {worked.time}, ... For example, in our company we use the formula {worked.time}

      /

      {resolved.story.points}

      . It would also be nice to be able to select the types of issues that need to be used to calculate the velocity. For example, only issues of the type "Story" are used in the calculations. Issues of the type "Bug" or "New Feature" are not used.

      The velocity implemented above, must be visible throughout the application. So not only in the administration module of JIRA, but also in version overviews, etc. Screenshots 2 to 5 are simple, possible examples.
      Also a chart that shows the progress/course of the velocity would be a must-have feature. It would show the progress of the team very well.

      The only thing that still has to be done, is integrating the use of the velocity into the issues. At our company, the velocity is used to calculate the estimated time for a story. There are 2 possible ways for implementing this:

      1. The first possible solution can be seen in screenshot 6. A checkbox is available next to the story points field. When checked, JIRA will calculate the "Original Estimate" using the velocity for the specified version and will bind this value to the "Original estimate" field. Any input into that field will be discarded. This calculation will happen every time the issue is copied/moved to another version. If the story is unscheduled, no calculation will be executed and the estimate will stay empty. Once the issue is resolved, the value will not change anymore. In the screenshot you can see that the story has 1.5 points assigned to it. If the Velocity for the given version is 2, then the original estimate will be 3 days. [Note: also here, it would be a possible admin feature to be able to adjust the formula like described above]
      2. The second possible solution can be seen in screenshot 7. Instead of using the "Original estimate" field, an extra field is introduced: "Calculated estimate". Everything else remains the same as in the first solution. The "Calculated estimate" field is a disabled field, which means that no user input is allowed.

      I hope that some of the people at Atlassian are eager to implement this feature in this or any other suggested way. Anyways, I already appreciate it if anyone took the time to read this long text.

      Thanks.

        1. Screenshot 1.png
          Screenshot 1.png
          37 kB
        2. Screenshot 2.png
          Screenshot 2.png
          23 kB
        3. Screenshot 3.png
          Screenshot 3.png
          18 kB
        4. Screenshot 4.png
          Screenshot 4.png
          27 kB
        5. Screenshot 5.png
          Screenshot 5.png
          16 kB
        6. Screenshot 6.png
          Screenshot 6.png
          35 kB
        7. Screenshot 7.jpg
          Screenshot 7.jpg
          37 kB

            [JSWSERVER-1829] Working with Velocity in JIRA Software

            Atlassian Update - 24 March 2025

            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

            Aakrity Tibrewal added a comment - Atlassian Update - 24 March 2025 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

            hkopf added a comment - - edited

            we were evaluating Jira Agile recently and the missing average velocity and future sprint calculations based on it are one of the top missing pieces for us.

            Working with homegrown tools up to now, we are frequently using estimations of future sprints using different velocities to see how progress would be in e.g. a) best case b) expected and c) worst case. Therefore you need a calculation of the average velocity from the last sprints, then a projection/estimation how the stories in the current backlog would be spread over upcoming sprints, and lastly a chance to tweak the velocity used for this projection/estimation to simulate the different velocities.

            Of course this only works if you have fixed length sprints, but that should be a typical scenario.

            To keep it short, one of the key question is (quite similar to GHS-8337):

            As a Product Owner I want to easily find out when a specific story in the backlog could be done with a given average velocity so that I can react to possible schedule changes as soon as possible.

            hkopf added a comment - - edited we were evaluating Jira Agile recently and the missing average velocity and future sprint calculations based on it are one of the top missing pieces for us. Working with homegrown tools up to now, we are frequently using estimations of future sprints using different velocities to see how progress would be in e.g. a) best case b) expected and c) worst case. Therefore you need a calculation of the average velocity from the last sprints, then a projection/estimation how the stories in the current backlog would be spread over upcoming sprints, and lastly a chance to tweak the velocity used for this projection/estimation to simulate the different velocities. Of course this only works if you have fixed length sprints, but that should be a typical scenario. To keep it short, one of the key question is (quite similar to GHS-8337 ): As a Product Owner I want to easily find out when a specific story in the backlog could be done with a given average velocity so that I can react to possible schedule changes as soon as possible.

            @Jose: yes this is possible but it will not calculate the velocity over the last sprints. Imo it should be possible to define per project how the velocity should be calculated. Example: take the last x sprints, add the story points together and divide them through x sprints. If GreenHopper would do that for you know what your velocity (how many story points per sprint) is and you can plan the next sprint accordingly to that amount of story points.

            Dirk Maucher added a comment - @Jose: yes this is possible but it will not calculate the velocity over the last sprints. Imo it should be possible to define per project how the velocity should be calculated. Example: take the last x sprints, add the story points together and divide them through x sprints. If GreenHopper would do that for you know what your velocity (how many story points per sprint) is and you can plan the next sprint accordingly to that amount of story points.

            There is a way to get the velocity: In Agile tab, go to Released Board. There you can see the list of released versions, which represent the different sprints. There is a "Statistics" button where you can add Story points. Doing this you will see the sum of story points of the stories inside a sprint. The ugly part of this is that there are two different story points fields in the issues, and both must be filled.

            José María Blázquez added a comment - There is a way to get the velocity: In Agile tab, go to Released Board. There you can see the list of released versions, which represent the different sprints. There is a "Statistics" button where you can add Story points. Doing this you will see the sum of story points of the stories inside a sprint. The ugly part of this is that there are two different story points fields in the issues, and both must be filled.

            We are using Studio with GreenHopper plugin and this is something what has to be implemented in order to to make it true agile plugin.
            We are looking forward to see it in comming version (I hope this will get enough priority and it will be implemented asap!)

            Peter Kobes added a comment - We are using Studio with GreenHopper plugin and this is something what has to be implemented in order to to make it true agile plugin. We are looking forward to see it in comming version (I hope this will get enough priority and it will be implemented asap!)

            This is exactly what I'm still looking for. Our current version is v4.1.2#531. Will this still be implemented?

            Dirk Jan Menkveld added a comment - This is exactly what I'm still looking for. Our current version is v4.1.2#531. Will this still be implemented?

            Being able to work with a velocity is quite important for working in a scrum way. Now we need to keep track of it manually, and plan sprints accordingly. This is done better in a lot of other tools...

            Marcel Blok added a comment - Being able to work with a velocity is quite important for working in a scrum way. Now we need to keep track of it manually, and plan sprints accordingly. This is done better in a lot of other tools...

            Changed priority

            Mano Swerts added a comment - Changed priority

            Added extra screenshots

            Mano Swerts added a comment - Added extra screenshots

              Unassigned Unassigned
              678c0f5bad83 Mano Swerts
              Votes:
              28 Vote for this issue
              Watchers:
              20 Start watching this issue

                Created:
                Updated:
                Resolved: