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

[Jeroen van Woudenberg]

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?

[Nic Brough -Adaptavist-]

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?

[Jeroen van Woudenberg]

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?

[Nic Brough -Adaptavist-]

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.