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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,773
Community Members
 
Community Events
176
Community Groups

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:

 

Screen Shot 2021-03-10 at 15.45.52.png

 

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.

 

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

 

This are the options I used on Auto-schedule:

Screen Shot 2021-03-10 at 15.52.02.png

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

1 answer

1 accepted

1 vote
Answer accepted
Dave Atlassian Team Mar 10, 2021

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!

Regards,

Dave

Hi @Dave 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

Like Dave likes this
Dave Atlassian Team Mar 11, 2021

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.

Regards,

Dave

Like Anita Cacic likes this

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

Dave Atlassian Team Mar 31, 2021

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

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?

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

  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

 

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

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, 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:

image.png

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PERMISSIONS LEVEL
Site Admin
TAGS

Atlassian Community Events