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

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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

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

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

Thanks,

Angus

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.

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

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
This widget could not be displayed.
TAGS
Community showcase
Published in Marketplace Apps & Integrations

The origin of Dashboard Hub: Atlasboard

First of all, I'm going to introduce myself. My name is Gorka, I work as product manager in Appfire Although this is my first public article in the community, I've been around since 2013. I starte...

227 views 4 19
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you