Sprint capacity working days allocated definition
Asked by Darry Lau:

Adv. Roadmaps version: 3.29.6

We are using Sprint Capacity view to manage the team and sprint.

Found the "Sprint Box" working days allocated are calculated by issues "Remaining Estimate". When sprint is close to the end , working days allocated will be lesser as issues are completing (have worklog and remaining estimate are reducing).  

Below is a demo. I created an issue with 2w (10 days) original estimate. I input worklog 5 days. Remaining estimate become 5d (10 minus 5). The sprint box working days allocated will show 5 instead of the original estimate 10d. It looks weird to my team. As we thought the working days allocated should be always counting "Original Estimate".

If we change the view to use Story Point, worklog would not reduce the story point in sprint box  

Anyone know the definition of "working days allocated" when using Days/Hours for display. Thank you.

![adv.JPG](/t5/image/serverpage/image-id/136342iF39D78E58C7D76CB/image-size/large?v=v2&px=999 "adv.JPG")


Answers:
author: Dave
body: Hi [@Darry Lau](/t5/user/viewprofilepage/user-id/4324698)

The weekly capacity will be configured for the team associated with the board that this sprint comes from (you can edit this on the "Teams" tab). So if you have a weekly capacity of 70 days, you've added a 10 day issue to the sprint and the sprint is 7% full then that would suggest that you have an iteration length of 2 weeks for each sprint.

However, I would agree that the fact that it says 5/70 working days allocated does look a little odd and I'll dig into this further. However to help me it would be good if you can confirm the weekly hours and iteration length configured for the associated team please,

Many thanks,

Dave

comments: author: Darry Lau
body: Hi Dave,

I set the team with 200 hours weekly with 3 weeks iteration length. That should be 25 working days for each iteration (I didn't set Holiday for the demo).

At the beginning, I assigned a 10 days issue (Original Estimate) in the sprint. It was 10/70.

Once I marked worklog on the issue for 5 days. Then the sprint box become 5/70.

This is why I wondering about the definition of "working days allocated" from the box.  
It seems calculating the "Remaining Estimate" instead of planned Original Estimates.

This is a bit confusing as the denominator (70) wouldn't change but numerator (10) keep decreasing. What I expect the numerator should be Original Estimate and always not change.

Thanks

Darry


author: Dave
body: Hi [@Darry Lau](/t5/user/viewprofilepage/user-id/4324698),

I've chased this up with the development team and this apparently is a known issue when estimating in time. The problem (as you've correctly hinted at) is because we are using the Remaining Estimate rather than the Original Estimate and as I understand it we're not actually loading the Original Estimate into the plan.

As you say, I think this is why we have that definition of "Working days allocated" - it's not actually reflecting the overall sprint capacity ... with 5 days completed of a 10 days issue, there are only 5 days left allocated. However, as you progress through the sprint the number of available working days is decreasing and I don't believe this is reflected - therefore it's not really showing progress.

This only really is expected to impact ACTIVE sprints though.... in theory you shouldn't be logging work for sprints that haven't been started, and in that case the remaining estimate would actually make sense as far as sprint capacity goes.

Personally I think this is a bug and have raised these issues for both Data Center and Cloud platforms:

* <https://jira.atlassian.com/browse/JPOSERVER-2965>
* <https://jira.atlassian.com/browse/JSWCLOUD-21402>

Unfortunately I don't know when these will be scheduled to be fixed. An interim solution might be that we simply stop showing this information on active sprints - this obviously isn't a solution, but would reduce the potential of further confusion.

Regards,

Dave


Tags: advanced-roadmaps