You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I believe with Advanced Roadmaps 3.22 (could have been a different version early/mid 2020), a new mechanism to calculate sprint capacity utilization was introduced. Before, Advanced Roadmaps displayed to what degree (% and story points/hours) a projected sprint was over- or under-allocated.
This is no longer possible. In our company we preferred the previous approach. Would it be possible to offer the option to use either?
The grouping and team assignment are in place.
Below you can see the printscreens for the utilization of defined and projected sprints. In the past the projected sprints worked the same way as the defined sprints. Since v3.22 the projected sprints show in green how much the utilization is (not providing % or story points), when red there is no mentioning of how much the sprint is over-planned.
At least as important as above, when planning an epic before v3.22, the effort was evenly distributed across all sprints set in the epic's target start/end dates.
As of v3.22, it appears that the epic effort is fully allocated to the first relevant sprint, even though the epic spans across multiple sprints. If there is not enough capacity in the first sprint, the remaining work is allocated to the next sprint, etc. For our teams, this new approach renders the capacity calculation pretty much useless. Would be very much appreciated to have the option to chose between the two approaches, on a global or per plan level.
@Angus Russellis there any plan to switch back to the previous sprint utilization calculation, or even better, offer both?
HI @Michael Brunschweiler , I don't believe there are any plans to offer the old calculation method as an option, because it was very primitive. All it did was divide the estimate of an issue between all the iterations it was assigned to, regardless of whether the iterations were in the past or the future.
The new capacity distribution algorithm is intended to distribute an issue's estimate in a way that more resembles how work actually gets done. I.e. past iterations will not consume any of the issue's estimate, and the issue's estimate will be greedily consumed by the earliest available iteration(s).
Can you please confirm - do you actually want to use the old algorithm, or do you just want to be able to see the allocated vs done progress bars in the sprint flyout again?
Hi @Angus Russell , if the old algorithm allocated remaining effort to past sprints that would of course be a huge deficiency. I have to trust you on that, as I cannot verify. In my opinion, not having any alternative to the "greedy consumption" is a big limitation to utilizing the capacity utilization effectively, as often not the entire team can work on the reflected piece of work (especially when using epics to plan further ahead). So this aspect we definitely preferred in the old calculation. Might be an option to offer the old calculation, just without spreading the remaining effort across historical sprints.
The greedy consumption does take team members into account. It's always assumed that one team member will work on the issue, not the entire team.
Here's a screenshot that illustrates this:
In this screenshot:
Hopefully it makes a bit more sense now?
Thanks @Angus Russellthis does make more sense. We had been using epics for longer-term planning, not having elaborated any user stories at that stage. Hence, multiple team members could work on an epic, but typically not all would. I'll play around a bit more with the current algorithm, and will get back to you, if we still have an urgent need to modify it.