Distributing Effort Across Projected Sprints

[Michael Brunschweiler]

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?

[Angus Russell]

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

[Michael Brunschweiler]

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.

[Michael Brunschweiler]

@Angus Russellis there any plan to switch back to the previous sprint utilization calculation, or even better, offer both?

[Angus Russell]

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]

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]

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:

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]

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.