What are the issues to calculate the committed points in the Velocity Chart?

In the Velocity chart I see that the committed points are 161 for a specific sprint. When I look further into the detail list in Jira, then I see 135 points for all issues without a *. So, I don't calculate the issues that are added after start of the sprint.

Where is the difference of 26 points coming from?

I have also calculated the the total points in the sprint --> velocity (101 points), issues removed from sprint (12 points) and issues not completed (117 points) = 230 points.

When I start with the committed points (161 points) + issues added to the sprint after start of the sprint (84 points) minus storypoints lowered (37 points) plus storypoints increased (48 points) then I have a total points of 256 points for the sprint. Instead of 230 points. Also a difference of 26 points.

I can not find the 26 points anywhere in Jira. so, my question is where are the committed points in Jira in the Velocity Chart coming from?

1 answer

0 vote

Does a search for "sprint = xxx" give you the issues that add up to 135 (or 161)?  Also, do you have any subtasks with story points on them?

this seems to be the richt way to look further.

I see 24 storypoints on subtasks and also 2 or 4 points on bugtasks, depending on the closed/resolution date of the bugtasks to link the bugtasks to a sprint xxx. In the issuelist in Jira, both bugtasks where part of our sprint 56. So, that means that I have to take 4 points in account. In that case I see a total of 28 instead of 26 to add to the committed points. 

The next quetion is: the velocity is 101 points. That is without the storypoints on subtasks. So, the velocity should also be increased with the delivered points of subtasks.

Is it right that the velocity is without delivered/closed subtasks?

Yes.  It's a bit of a pain in the neck.  Atlassian have coded Software in a way that avoids them having to deal with roll ups and splits of estimates on sub-task issues (as there's several ways to approach handling them and they'd have to cope with all of them).  This means the rule for estimating subtasks is "don't".  Just don't put estimates on sub-task types, as you'll see some very strange behaviours and numbers that don't work.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published yesterday in Jira Service Desk

Wy are we still using email for Service Desk workflows?

...attest to the experience of an urgent approval that gets lost in the boss’s inbox and requires that special “Please Approve” email or text message. In an age where we have distributed teams...

111 views 0 2
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you