Uploaded image for project: 'JIRA Software Server (including JIRA Agile)'
  1. JIRA Software Server (including JIRA Agile)
  2. JSWSERVER-1829

Working with Velocity in JIRA Software



    • Feedback Policy:
      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 An updated workflow for server feature suggestions.
    • UIS:


      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



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



      . 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.



        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

          Issue Links



              • Assignee:
                mano.swerts Mano Swerts
              • Votes:
                28 Vote for this issue
                20 Start watching this issue


                • Created: