You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
Hi @Darry Lau
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,
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.
Hi @Darry Lau,
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:
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.