I have a team that manually sets fixed releases to their issues. The length of the release is 1 quarter (start date = first day of the quarter and end date = last day of the quarter). They have defined their teams and assigned the team members. They use scrum-ban so have a weekly story point velocity assigned. The story backlog is prioritized. Some of their issues have been groomed and estimated (so story points assigned + the manually set release). Ungroomed issues just have the manually set fixed release. Due to the nature of their planning method, their releases have a lot of issues assigned.
When I Auto-Schedule the plan, the unestimated issues all have the same Target End date, but it's about 45 days past the fixed end date of the release. The team does not want to overwrite their manually set release, so that is set to "empty values only". What is the tool taking into consideration to push the date out for unestimated issues? I would have expected that the Target End date would have been set to the last day of the fixed release (May 31). Is it taking into consideration the number of issues in the release (estimated and not), size of the team and/or velocity, and any dependencies? I included a snapshot showing issues using the manually set fixed release (end date of May 31, 2021) in combination with their estimated issues so you can see the dates line up. Thank you.
In the screenshot you've shared, is that showing after proposed auto-scheduled changes have been accepted?
I can see that all of the dates have the triangle change indicator which means that they've been changed within a plan - are these the dates that have been changed manually?
Also, the majority of the issues don't appear to have an estimate assigned to them which essentially means that the auto-scheduling algorithm will ignore them and just use the dates that have been manually set.
The dates with the triangle are those I have accepted after the auto schedule. The target start and target end were calculated from the auto schedule. The issues are not estimated, but the release has a fixed end date of May 21. It's the release that the team sets manually, but the target end is auto calculated. Everything is working as expected except I am unable to explain to the team why the unestimated issues have a Target End date of July 14 when the fixed end of the release is May 21. If the auto schedule is pushing the unestimated issues past the end date of the fixed release because they have more work than capacity and/or dependency problems, they would understand that. I just haven't found any documentation to confirm this behavior, thus they don't trust what they see.
Thanks for that clarification @Jennifer Maguire, my apologies for misunderstanding your original question! You're absolutely right, that does seem strange... if the end date is beyond the fixed date of the assigned release and it doesn't have an estimate then I definitely agree it shouldn't be pushing the date past that release date. This is potentially a bug... you've tagged this question as being on Server. What version of Advanced Roadmaps are you currently using?
Also, is this the only release in the plan?
We are on Jira v8.5.4 and Advanced Roadmaps for Jira v3.29.6.
It is not the only release in the plan. This team is new to Advanced Roadmaps, so they have been using FixVersion(s) to bucket work. They probably have at least 3 different release names all with the same fixed start and end (which is why they have been setting and changing them manually). They probably have at least 10 other releases imported into the plan.
If we change the velocity of the team, it changes the dates of those unestimated issues. They really do have a lot of issues assigned to the fixed releases. I've removed the release information for a large number of them and auto-scheduled. Issues unestimated and no release are ignored. Issues unestimated and have a fixed release now have a target date of May 27 (so not over booked, but not May 31). I haven't encountered this before.
Unless I'm missing something, this definitely sounds like a bug to me and I would recommend raising a support request so we can get this fixed. Changing the velocity of a team should have no impact on the dates of an unestimated issue. Something definitely doesn't sound quite right and it would be good to have a support engineer dig into this in more detail!