Recent change to how "hours of estimated work" is calculated and red (over) / green (under)

Jordan Gipple January 13, 2022

View Settings = "Group by Team" with "show capacity on timeline." 
Team type Kanban
Jira server v8.20.3.
 

The calculation for showing capacity on the timeline has recently changed in a way that makes it much less useful for our Kanban team. I am curious if others have figured out a workaround that recreates the view how it used to be.

Our Kanban team's capacity "bars" used to go red and show how much we were overbooked in each time unit with capacity "consumption" from each issue spread evenly over the issue's duration.

Recently the capacity "consumption" from each issue will not exceed the team capacity and go red until the time period where the issue is scheduled to end. 

For example here it shows we are green:

2022-01-13_5-44-23.png

All of the remaining hours are moved to that time period where the issue is scheduled to end:

2022-01-13_6-18-28.png

 

The 1016 excess hours used to be charged evenly to the capacity and now it is all backloaded. 

I can imagine that some people would say that this is an improvement that is more accurate for Kanban teams since you are by definition always at exactly full capacity (never over and never under). This way of presenting the information tells you won't finish one or more issues by their current deadlines - that you need to extend the deadline or remove issues until it goes green.   

However, this change makes the capacity on timeline view much less useful to us. Before, we could easily see the first time period with a deficit (where the deficit starts. Now we can only see that a deficit exists but it is challenging to find where it started and that make it much harder to play around with the issue start dates to avoid getting overbooked.

I suspect that the "correct" solution is to convert our team type to scrum and put our issues in sprint timeboxes. But that is a bit of a hack for us since these issues are long term initiatives (projects) that can range from 3 month to 3 years so they would easily span multiple sprints. I don't want to have to split each project up into multiple issues with the hours divided up since that would add overhead.

I hope my description makes sense, but please comment if clarification would help. 

Any suggestions would be greatly appreciated!

Thanks!

0 answers

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events