Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Distributing Effort Across Projected Sprints

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?

1 comment

Angus Russell
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Feb 11, 2021

Hi @Michael Brunschweiler 

You should still be able to see the capacity of projected sprints. Can you confirm that you are grouped by team or sprint, and you've ticked "Show capacity on timeline" in the view settings?



Like Dave likes this

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?

Angus Russell
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Mar 28, 2021

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.

Angus Russell
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Apr 05, 2021

Hi @Michael Brunschweiler ,

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:

Screen Shot 2021-04-06 at 9.26.51 am.png

In this screenshot:

  • Team 3 has two team members and a 30 point sprint velocity
  • Issue B is a 30 point issue, but it only takes up half of sprint 3 because only one person is working on it (30 point sprint velocity / 2 team members = 15 points each)
  • In Sprint 4, the remaining 15 points of Issue B and 15 points of Test 8 are allocated
  • The first projected sprint is only half full because only one assignee is assumed to be working on it
  • In the second projected sprint, there are still 70 points of Test 8 remaining but only 30 points of capacity, so that sprint is marked as overbooked.

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.


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events