Distributing Effort Across Projected Sprints

Michael Brunschweiler February 11, 2021

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

Thanks,

Angus

Like Dave likes this
Michael Brunschweiler February 12, 2021

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.

utlilization_defined_sprint.pngutilization_projected_sprint.png

Michael Brunschweiler March 26, 2021

@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.
March 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? 

Thanks,

Angus

Michael Brunschweiler April 1, 2021

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.
April 5, 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

Michael Brunschweiler April 6, 2021

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.

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events