Auto-schedule overbooking sprint
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:
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?
1 answer
1 accepted
@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:
- Plan has a hierarchy of initiative > epic > issues
- We use hour estimates and weekly sprints
- 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:
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:
- The sprint is being overbooked by 83 hours by the autoscheduler
- 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, 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.
- Screenshot I get when I try to access the page for understanding capacity:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.