Greenhopper report and burndown chart do not show story points correctly / at all with custom field for points

[John V]

Greenhopper report and burndown chart do not show story points correctly / at all with custom field for points

1. I have created a new custom field called Task Points that is associated with sub-tasks and bugs.

2. I have created stories and sub-tasks for the stories. The stories have story points.

3. The sub-tasks have task points instead of story points.

4. I have configured the greenhopper board to measure time in units of Task Points

5. I have entered estimates for the task points for the sub-tasks both before the sprint started and after it started

6. I start the sprint and the burndown chart starts at 0, I look at the sprint report and it shows - for the entry of each sub-task under task points yet the sub-task points are properly shown in the sprint cards.

This is not the same as below as none of the task points show up even those created before I started the sprint and there is no resetting to zero, the task points are correct in the task but not shown on any of the reports or the burndown chart.

https://answers.atlassian.com/questions/115210/story-points-not-visible-and-not-counted-for-in-report-view-jira-greenhopper

[Matthew Hunter]

Hi,

The short answer is, the reason why the task points aren't appearing in your burndown is because they are only recorded against sub-tasks. No estimates measured against sub-tasks will appear in the burndown chart. The reason for this is best described in this blog post:

Many teams break down stories in to sub tasks shortly before the sprint begins so they can use the stories for tracking. This raises the possibility of using the sum of the estimates on the sub-tasks as a way to decide which issues to commit to in the sprint (and potentially for velocity).

As described above, tracking is really a separate process from estimation and velocity. The estimates that are applied to the sub tasks are clearly higher accuracy than those that were originally applied to the story. Using them for velocity would cause the velocity to have both high and low accuracy estimates, making it unusable for looking looking further out in the backlog where stories have only low accuracy estimates. In addition, only items near the top of the top of the backlog are likely to have been broken to tasks, so using task estimates for velocity means that the velocity value could only ever predict the time to complete the backlog up to the last story that has been broken in to tasks.

Using the sub task rollup to decide the sprint commitment would also be dangerous because unlike the velocity value it does not take in to account the overhead of unplanned work or interruptions.

Your best solution would be to use the estimates against stories to track your burndown.

Cheers,

Matt

[John V]

I understand the issue raised in the blog post above. That is why I created a separate metric for sub-tasks than stories because as indicated in the blog it is hard to mix them. So long as I choose to measure my sprint in one or the other the metric is relevant to be compared to each other. So if I have a sprint with stories that have all been broken down into sub-tasks then I can choose to measure that sprint in task units instead of story points. Since the stories have story points and the tasks have task points, there is no expectation of adding them together as they are different units.

I was happy that it appeared Greenhopper allowed me that choice by allowing me to define a custom field and then allowing me to determine in the configuration of the board that I measure my sprint with my newly created unit as shown on the image attached.

What is expected is that the sum of all the task points at the start of the sprint are shown as the burndown total and as configured in the board configuration settings that they be used as the burndown unit. It may not be how other people choose to run sprints, but if I want to run my sprints with task points instead of story points and greenhopper lets me configure it to do so and then fails to report it properly it is a bug.

[Matthew Hunter]

Unfortunately though, it's not possible to track that statistic on sub-tasks. When choosing an Estimation Statistic you need to ensure it's the type used by the parent issues, as the child issues will not appear in the burndown.

We did have a feature request open for sub-task estimates that you can find at https://jira.atlassian.com/browse/GHS-5283. We released a change in GreenHopper 6.0.3 that allows you to do some minor time tracking on sub-tasks, however it is still not the recommended way to work within GreenHopper. You can check out the release notes for GreenHopper 6.0.3
for details.

[John V]

I get a "project does not exist" error when clicking on the feature request link.

I don't want to use time tracking, I want to use points tracking but have the ability to include sub-task points in the estimate and burn-down. I am very surprised this is does not work.

Let the user manage the issues related to correlation between sprints or tasks and sub-tasks, but don't prevent a fundamental feature from working due to this concern.

What is the usefulness of sub-tasks if you canot use them to count towards tracking?