Uploaded image for project: 'Jira Align'
  1. Jira Align
  2. JIRAALIGN-4997

The Kanban Team velocity calculation in Forecast is confusing

    • 2
    • Severity 3 - Minor
    • No

      Issue Summary

      Kanban teams don't have sprints so the velocity should not be calculated as for agile teams.
      Kanban teams have throughput, but throughput is calculated differently, and treated differently in the Forecast than it is in the Program Board (mainly because Jira Align is treating throughput as velocity, even though they are different fields).

      Steps to Reproduce

      N/A

      Expected Results

      To be determined by the Product Manager.

      Actual Results

      In the forecast, the throughput is calculated like this: anchor sprints x number of stories accepted in the past 5 weeks.

      In the program room, throughput is calculated like this: number of weeks in a PI x number of stories accepted in the past 5 weeks.

      Workaround

      Currently, there is no known workaround for this behavior. A workaround will be added here when available

          Form Name

            [JIRAALIGN-4997] The Kanban Team velocity calculation in Forecast is confusing

            How shall this new capacity feature work for Kanban team, as this ticket is about forecasting for Kanban teams?

            We have Programs which contains Agile teams and Kanban teams. How shall this work?

            1. If  I use Points system, do I need to calculate those manually for Kanban teams or will they somehow get converted by using the Throughput?
            2. If I use the Bulk edit for Sprints and choose 'Anchor sprints' I will end up with 0(=zero) Sprints for each Kanban Team. Multiplication with zero -> no capacity?
            3. In the new capacity feature the user has to enter Points per Sprint and the number of Sprints... so you expect that each Sprint the Team works with the same capacity. But there are Sprints where usually a lot of Team members take vacation. How to deal with that? Shall I calculate the whole capacity over all Sprints manually and afterwards divide by number of Sprints to deal with this? 

            To be honest, I doubt that our Team leads and Scrum masters will choose to work with the new capacity feature instead of using Excel. 

            Carmen Popp added a comment - How shall this new capacity feature work for Kanban team, as this ticket is about forecasting for Kanban teams? We have Programs which contains Agile teams and Kanban teams. How shall this work? If  I use Points system, do I need to calculate those manually for Kanban teams or will they somehow get converted by using the Throughput? If I use the Bulk edit for Sprints and choose 'Anchor sprints' I will end up with 0(=zero) Sprints for each Kanban Team. Multiplication with zero -> no capacity? In the new capacity feature the user has to enter Points per Sprint and the number of Sprints... so you expect that each Sprint the Team works with the same capacity. But there are Sprints where usually a lot of Team members take vacation. How to deal with that? Shall I calculate the whole capacity over all Sprints manually and afterwards divide by number of Sprints to deal with this?  To be honest, I doubt that our Team leads and Scrum masters will choose to work with the new capacity feature instead of using Excel. 

            This is fixed as part of our new capacity feature. Check out these release notes for more information: https://help.jiraalign.com/hc/en-us/articles/20414760382996-Release-notes-for-10-126-X

            Jake Comito added a comment - This is fixed as part of our new capacity feature. Check out these release notes for more information: https://help.jiraalign.com/hc/en-us/articles/20414760382996-Release-notes-for-10-126-X

              dfuller@atlassian.com Don Fuller
              646db21d89d1 Francois Panaget
              Affected customers:
              1 This affects my team
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: