Why is Advanced Roadmaps miscalculating sprint capacity?

[Rob Horan]

See the image below.  Assume:

• 3 week sprint
• 5 days per week
• 5 person team

Sprint capacity should then be 3 * 5 * 5 which is 75. 

Sprint capacity is missing 5 days here.  Where did the time go?

[Curt Holley · Accepted solution]

March 7 to March 24 is only 14 business days, not 15.
As 24 is a Thursday.
So 75 - (1x5 people) =70

[Rob Horan]

I must have looked at the calendar 10 times and didn't see the Thursday end, thank you!

[Rob Horan]

I see why I made the mistake.  You can't see it because the name of the sprint was blurred, but the sprint name had the end date in it, and it said March 25.  The sprint end date was chosen incorrectly.

[Rob Horan]

@Curt Holley Sorry, but I'm confused again.  The sprint ends on the 25th - why is Roadmaps showing the end date as the 24th?

[Curt Holley]

Good question @Rob Horan I think it must have to do with timezones as I've got the same issue. 
Like Advanced Roadmaps is on a different timezone to jira...or something. 
What timezone as you on compared to Jira time, as I am out by 12 hours, so get these oddities from time to time.

[Rob Horan]

Good to know, thanks @Curt Holley !

Do you know how I can identify issues that are scheduled but not in a sprint?  I can't seem to find a way to identify them.  

They're not coming back from filters that use any of the date fields I am aware of. I can't find a view in Roadmaps to identify them.

[Curt Holley]

What do you mean by "scheduled" @Rob Horan ? I'm struggling to picture what you mean.

[Rob Horan]

In this case I'm actually using Jira's terminology :)

"Issues that are scheduled during a sprint but not assigned to it still consume capacity"

What I have gathered is two things:

1. Jira is consistently getting sprint date wrong, and truncating it, which decreases working days and also seemingly overlapping sprints.
2. Unresolved issues from older sprints are rolling in with inferred start/end dates that are not part of the issue data, and therefore cannot be identified via JQL.

[Curt Holley]

Right, due to the overlapping dates.

I would raise this with Atlassian support, but my money is on it (the date discrepancy) being timezone related (which sux).

Just out of curiosity, what time of day did the sprint that ended on March 7, end? was it prior to or after 11.41am (your timezone).

[Rob Horan]

Thanks - I'm still trying to find a way to identify these 'scheduled but not assigned' tickets via JQL.  Is there any way to do so?

[Rob Horan]

@Curt Holley - it's a bug.  I got this from support

After further investigating and checking with my colleagues Advanced Roadmaps considering the sprint as ending a day before the actual date set is currently a known bug:

• In a plan, sprints end one day sooner than the actual end date in Jira

I'm afraid I cannot give you an ETA on the fix. I suggest you add yourself as a watcher this way you will receive future updates on the bug, you are also encouraged to share your feedback there as this will help our team understand how it is affecting you. You can check more information on our Bug fixing policy at this link.

That being said a possible suggestion would be to set the end date of the sprint to one day after the actual date. You can continue to complete the sprint on the correct date as this will override the end date back to the correct date, but setting the end date to a day after could solve the last day problem.

Also, since this essentially answers my other questions, I'm going to leave this here for anyone else who might need this information:

Regarding the previous sprint problem, as mentioned before Advanced Roadmaps only considers and displays the dates and does not change the dates of the sprints themselves.

When you complete a sprint in Jira, the current date is set as the sprint end date and overrides the previous date set. In your case despite having set the end date to March 4 the sprint was actually closed on the board on March 8 at 12:35 pm, so the end date was overwritten with the actual date of when a user completed the sprint on the board. This is the sprint normal behavior and is not related to the Advanced Roadmaps.

Regarding the questions:

When looking at a sprint in a plan, how can we isolate the issues that have been scheduled during a sprint but not assigned to a sprint, yet are consuming sprint capacity?

• This is a little tricky as it is hard to differentiate which issues are assigned to the sprint and which are not in the Plan view, the best approach would be to search for them using a JQL.
• You can look for issues that are between the sprint dates and not part of any sprint by performing the JQL:

  ((duedate >= "2022/03/07" and duedate <= "2022/03/25") or ("Start date[Date]" >= "2022/03/07" and "Start date[Date]" <= "2022/03/25")) and sprint is empty
  

• This works for the current sprint for the next you would have to change the dates accordingly. This JQL returns all issues that have a due date or a start date during the sprint and are not assigned to a sprint.

In the absence of date values in these issues is there a JQL statement that could identify these issues?

• This can only happen if you are using inferred dates based on the Sprint dates and the sprints overlaps, for this case I'm afraid the only option would be checking the previous sprint stories and setting a due date to them before the new sprint start date.

Lastly, if an issue rolls over from a previous sprint, will it continue to consume capacity, even if it is closed at the start of the current sprint?

• Yes, any issue that has a start or due date between the current sprint dates will be counted for the capacity.

[Natalia Saranti]

Hello, 

Seems that this is still an issue, anyone found an easier work around. We are currently forecasting items in future sprints but since a sprint starts and finishes the same date (Friday) seems that issues are counted in both sprints, or at least a small part of them, and we get the warning of "issue not assigned to sprint" cause they are actually in another sprint. 

I tried editing the time the sprint ends and finishes so that they don't collide but still have the same, story points being allocated in both sprints, cause they share the Friday I assume. 

When I filter issues only by the sprint they are assigned I can see the actual result of how much of the sprint capacity is allocated and how much is still free, but when i don't do that I see the sprint full. 

Another workaround was to move all issues to a start date of Saturday and that also worked. 

Anyone else knows how to configure that start and end date better, looking at the time somehow so that issues are not counted in both sprints? or a way that issues are not counted in both sprints unless specified in the sprint field?

Thanks for the help in advance,

Natalia

[Jeff Ermalinski]

I had similar issue after setting Epics Target start and Target end dates and having Filters set to show From Epic To Story level.   I went into the plan configuration and the changed the Scheduling to use the Start date instead of the Target start.  Seems when the Target start was set it caused issues to show up in the capacity even when they were not planned for the sprint.  The Start date for mine is not set and that seemed to make Adv Roadmap capacity plan "happy" (accurate) when grouping by sprints