You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I have created a plan with following setup:
I have turned on sprint capacity view and used auto-schedule, as a result I have a plan that looks like this:
I wanted to try out manage sprint capacity option that was described here so I changed it for Sprint 1 to be 3 days instead of default 5.
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.
This are the options I used on Auto-schedule:
What is causing this issue? Am I doing something wrong?
Hi @Anita Cacic ,
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!
We've raised the following issues for this problem on both Cloud and Server platforms:
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.
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.
@Dave - 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:
When auto-scheduling the work, several sprints end up overbooked:
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).
To me, I see 2 issues here:
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, 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 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.