Auto-schedule overbooking sprint
Asked by Anita Cacic:

Hi all,

I have created a plan with following setup:

* issues grouped in epics
* added estimates and team
* created team with 1 week iteration length and 37,5h capacity
* used only one dependency

I have turned on sprint capacity view and used auto-schedule, as a result I have a plan that looks like this:

![Screen Shot 2021-03-10 at 15.45.52.png](https://community.atlassian.com/t5/image/serverpage/image-id/133874iFA7D8532EEB4BA8E/image-size/large?v=v2&px=999 "Screen Shot 2021-03-10 at 15.45.52.png")

I wanted to try out manage sprint capacity option that was described [here](https://confluence.atlassian.com/advancedroadmapscloud/understanding-sprints-998651205.html) so I changed it for Sprint 1 to be 3 days instead of default 5.

![Screen Shot 2021-03-10 at 15.48.43.png](https://community.atlassian.com/t5/image/serverpage/image-id/133877i1C4D4CF243A7D71B/image-size/large?v=v2&px=999 "Screen Shot 2021-03-10 at 15.48.43.png")

By clicking on Auto-schedule I would expect work that is currently in sprint 1 to be moved to the following sprints. What actually happened is that all work is assigned to Sprint 1 and it gets even more overbooked.

![Screen Shot 2021-03-10 at 15.52.15.png](https://community.atlassian.com/t5/image/serverpage/image-id/133879iD95BB26FA2DEEA36/image-size/large?v=v2&px=999 "Screen Shot 2021-03-10 at 15.52.15.png")

This are the options I used on Auto-schedule:

![Screen Shot 2021-03-10 at 15.52.02.png](https://community.atlassian.com/t5/image/serverpage/image-id/133880i4925B5DFA491A826/image-dimensions/240x270?v=v2 "Screen Shot 2021-03-10 at 15.52.02.png")

What is causing this issue? Am I doing something wrong?


Answers:
author: Dave
body: Hi [@Anita Cacic](/t5/user/viewprofilepage/user-id/4299115) ,

Thanks for raising this question.... we've had a quick investigation and it seems like this is a bug. It does work as expected for story point estimation but not for time based estimation. We're going to do some further investigation and verify where the problem is and resolve this issue. We really appreciate you bringing this to our attention and are very sorry for the inconvenience that this is causing!

Regards,

Dave

comments: author: Anita Cacic
body: Hi [@Dave](/t5/user/viewprofilepage/user-id/1183605) thank you for your answer. I would highly appreciate if you could get back to me after further investigation with expected resolution date. It is important to me so we can start using this feature across our organisation.

Regards,

Anita


author: Dave
body: We've raised the following issues for this problem on both Cloud and Server platforms:

* <https://jira.atlassian.com/browse/JSWCLOUD-21333>
* <https://jira.atlassian.com/browse/JPOSERVER-2952>

Unfortunately at this stage I can't comment on how quickly we'll be able to get a fix out for this, but by watching these issues you should be able to track progress.

Regards,

Dave


author: Aaron Collett
body: How could this possibly be considered a low priority bug, isn't it a key element of advanced roadmaps?


author: Dave
body: It's not that it's a "low" priority bug, it's that it's a "lower" priority bug than other work on our backlog.

To give you some insight into this, our analytics tell us that the auto-scheduling functionality is not a highly used feature of Advanced Roadmaps. You could argue that this might be that this is because there are issues with it that need to be addressed that prevent people adopting it.

However, we have considerably more work on our backlog than we have developers available in the team to address (this comprises platform support work, feature requirements, bugs, engineering health work) and this all has to be prioritised based on the relative merits and value that it brings. Fixing this bug is likely to have a lower impact than other work, and therefore this lowers it's priority relative to other work that will have a greater impact.

Regards,

Dave


author: spablos
body: Should we avoid auto-scheduling then? does this problem is limited to some certain type of use. or the Auto Scheduling feature is just no usable?


author: Megan Killeen
body: [@Dave](/t5/user/viewprofilepage/user-id/1183605) - hello! I am helping my team move from Live Plans to Advanced Roadmaps and am experiencing this same/similar issue. Can you help troubleshoot?

For our set up:

1. Plan has a hierarchy of initiative \> epic \> issues
2. We use hour estimates and weekly sprints
3. We've manually adjusted the velocities of sprints to better reflect team capacity on a week by week basis (need this for realistic timelines with PTO + holidays)

When auto-scheduling the work, several sprints end up overbooked:

![Screenshot 2021-07-22 193714.png](https://community.atlassian.com/t5/image/serverpage/image-id/152481iD8F1C81E0D06E58A/image-size/large?v=v2&px=999 "Screenshot 2021-07-22 193714.png")

I've tried (1) clearing all dates + sprints and then (2) hitting auto-schedule again to see if that would help, but it yields the same results: overbooked sprints.

When filtering down to see the issues listed for the sprint, it looks like the full value of each 70 hour item auto-scheduled is being added into the total for the given sprint (R in this case), despite being shown as spread across 3 sprints (R, S, and T).

![Screenshot 2021-07-22 193911_LI.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/152484i828963462B7B9720/image-size/large?v=v2&px=999 "Screenshot 2021-07-22 193911_LI.jpg")

To me, I see 2 issues here:

1. The sprint is being overbooked by 83 hours by the autoscheduler
2. The item on the "fringe" (i.e., next in priority, but valued at more hours than available) isn't being split across sprints capacity-wise as a user would expect given your documentation

For issue #1 -- looking at the screenshot, I would expect 1 of those 70hr items at the bottom to be pushed to a later sprint since it definitely doesn't fit in the sprint given the capacity available (pushing the last 70hr item to the next sprint would take us from being 83hrs over to 13hrs overbooked).

For issue #2 -- let's imagine that my expectation in the last bullet was true. This would take us from 83 hours over capacity to 13 hours over capacity in this scenario, which means the other 70hr item (the one that we can partially keep in the sprint) would be split 57hrs in sprint R; 13hrs in the next sprint.

This expectation is based on your documentation on [this page,](https://confluence.atlassian.com/advancedroadmapsserver/auto-scheduling-issues-967895245.html) where it says:

*
  > When auto-scheduling work, the team's capacity will be treated in a more precise way. The scheduler will break down the time-based estimates, and then assign work to days based on how much free capacity there is in each day. For example, if ABC-123 has an estimate of 6 hours, and there's only 2 hours of free capacity for 27th May 2019, then the scheduler will schedule 2 hours on 27th May, and 4 hours on 28th May.

While visually this concept appears to be represented by the purple bars spreading 2 sprints, I don't think breaking down the estimates is happening in practice since all of the hours are being allocated to the first sprint for the 70 hr items.

I tried to follow the link in one of the subsequent bullets in your documentation about understanding capacity, but it appears to be a broken/forbidden link.

*
  > You can drill down in the capacity details by clicking the capacity bar of the sprint. See [Understanding team capacity](https://confluence.atlassian.com/advancedroadmapsserver/understanding-team-capacity-974360319.html)for more details. Note that the precise allocation of capacity (as you see in how issues are scheduled in the timeline) will not be reflected in the capacity details.
* Screenshot I get when I try to access the page for understanding capacity:

![image.png](https://community.atlassian.com/t5/image/serverpage/image-id/152485i9219D30EEDA6317B/image-size/large?v=v2&px=999 "image.png")


Tags: advanced-roadmaps

cloud