Easier way of velocity tracking?

[Lars Polling]

Currently we are sizing on parent issue level (in points) and perform the nett hour estimations on sub-task level as part of the work break down as part of the release planning meeting. The velocity of the team is calculated based on the work logged on the sub-tasks. These sub-tasks represent the different activities/steps of the workflow, like analysis, build, test, etc.

Problem is that often the work break down, including estimates in hours (on sub-tasks) is not complete or too much hassle is involved (like with low effort issues). Bottom line, this way of working seems not sustainable.

Is there an easier way of tracking the velocity in hours and still keep insight in the individual activities/steps?

Any similar experience or example?

[Renjith Pillai · Accepted solution]

Frankly velocity calculations are not based on Hours for release planning. The parent issues should be sized based on a relative item and velocity should be estimated based on the same.

And greenhopper directly will show the release planning burn down based on the custom field 'Story Points' which is filled as per the explanation give above.

The only challenge in this process that you will face is arriving at a base story which is considered as value 1 which is understood by all the teams that are involved in story point estimation.