When using the Time Tracking feature for a board the ideal line on the burndown chart is missing

[Mark Meade]

We are using Greenhopper v6.2. We have set the Time Tracking feature of our boards to “Remaining Estimate and Time Spent” so that our teams have their sub-task estimates visible in Work mode and they can easily update them. This feature also affects the burndown chart. Instead of seeing a story points burndown, we see hours. This is fine. The problem we have is with the ideal line on the burndown chart.

Once we start the sprint, we then create the sub-tasks necessary to support the stories (during our sprint planning). When we do this the burndown chart does not create an ideal line (assumingly because when the sprint starts there are 0 hours associated with non-existent sub-tasks). For example, we start a sprint on May 13, the team then adds their sub-tasks on May 14^thduring sprint planning. There is no ideal line on the burndown chart.

If we change the start date of the sprint (to a date after the sub-tasks are created) after the sprint actually started, the burndown chart contains a more appropriate ideal line. To continue with the previous example, if we change the start date of the sprint to be May 15th then we see an ideal line in the burndown chart.

The dilemma … do we keep the sprint start date as the real start date of the sprint and forego the ideal line in the burndown chart, or do we falsely alter the start date so that we see an ideal line in the burndown chart. What we really want is both, the accurate sprint start date and an ideal line in the burndown chart. If we don’t use time tracking then our burndown chart shows the ideal line because the story points are known when the sprint starts (but we want the team to see their estimates in Work mode).

Is there a way to get an ideal line in a burndown chart with Time Tracking on (and maintain accurate sprint start dates)?

Thanks,

Mark

[Meade_ Mark]

We have been moving the start date past sprint planning to see the ideal line.

[jlhuertas]

We had the same problem here and we are a bit newbies to agile/scrum, so I'm not sure if we are doing it the way it is suposed to be done.

The product owner usually creates the issues in the backlog but at that point they are not estimated. When we plan the sprint, we have to detail the issues and estimate them (sometimes creating subtasks) and we only add them to the sprint once they are estimated. After that, we start the sprint and this way whe ideal line on the burndown is created. The problem is that the planning meeting becomes really long and technical to be able to estimate the issues.

Just my 2 cents,

Jose Luis.