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

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


1 badge earned


Participate in fun challenges

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


Gift kudos to your peers

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


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!


Sprint capacity planning behaving oddly?


I would like to better understand how a ticket's estimated hours is split over sprints when the ticket spans into two projected or future sprints.

I have a plan with only one ticket with hours estimated for simplicity. It has 10d in its Time Remaining estimate and my future sprint is set to 5d and lasts a week.

If on the timeline I make that ticket start and end in that future sprints week it correctly shows 200% capacity. Planning 10d in a sprint of 5d is expected and all is behaving well.




When i make that ticket last two sprints I would expect both sprints to now be at 100% capacity - each with 5d in them. But instead it splits it in some manner I cannot understand. Why does it split them in 2.5d in one sprint and 7.5d in the second sprint?



Should it not be 5d in one and 5d in the next?

1 answer

1 accepted

5 votes
Answer accepted

Typical that I would find the answer myself after posting a question...

Let this help anyone else struggling with similar issues as the current documentation I feel is lacking and there is not enough guidance in the app.

The above behaves as expected if my Team has only one staff member in it. It had 2 in it - and therein lies my initial mental collapse.


Team members: 1
Sprint capacity: 5d
Ticket Time: 5d

This scenario behaves as you would expect. The ticket can be completed in one sprint. That sprint will be at 100% as expected. Even if I stretch the ticket over 2 sprints, it will still have the first sprint at 100% and the second at 0%.

Changing the Team members to 2 and leaving the Sprint capacity at 5d was my flaw, I should have updated the sprint capacity to 10d... because I have an extra set of hands!

My sprint capacity is divided by the team members (one issue per team member).
This means that the sprint capacity of 5d with two team members allows for 2.5d each. meaning the remaining 7.5d has to be completed in the last sprint - causing it to go red of course.

So if my sprint capacity is 5d per person and there are 2 in my team the total capacity should be 10d. 10d / 2 staff = 5d. Spreading the ticket over 2 days splits it evenly 5d each.

Hope this helps others!

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events