How to interpret the data?

[anonymous]

I'am using TimingAndEstimationPlugin and RoadmapHoursPlugin. Looking for an BurnDown-Chart I've tried to use EstimationToolsPlugin. The macros in a milestone view produces following output (see attachement)

BurndownChart

• see #4300

WorkloadChart

• remaining hours:
  • in the milestone gauge: 19h
  • in the workload chart: 27h, which seems to be the total hours. Maybe you look at estimated hours only. It will be nice to use (estimated_hours - total_hours) of TimingAndEstimationPlugin
• 10 workdays left: is this correct? For me it's a little bit too much. ;)

HoursRemaining

• same as above: estimated hours versus (estimated_hours - total_hours)

[anonymous]

Comment: I am not sure if this explains the numbers, the way this plugin works is that it takes one custom field and uses it to calculate estimated hours (you can interpret this as remaining hours, also see #4256). The screenshot shows 19 and 27 "remaining hours", looks like different plugins calculate in different ways?

[anonymous]

#4300 was fixed so I've added a new screen shot.

Now, BurndownChart shows the estimated hours as the other macros too. The graph is increasing. I've added tickets with estimated hours > 0. Also I modified some tickets adding worked hours. In my opinion the graph should decrease and show the remaining hours (=estimated_hours - total_hours).

I would like to see the estimated hours and worked hours in a project. If I use only estimated hours which will be count down by developers I have no idea of spent worktime and can't create a billing report for our customer.

Will change to enhancement because it seems to be the kind of working with scrum.

[anonymous]

Replying to anonymous:

Comment: I am not sure if this explains the numbers, the way this plugin works is that it takes one custom field and uses it to calculate estimated hours (you can interpret this as remaining hours, also see #4256).

I would join the idea of #4256. In my projects I have the need to monitor the remaining and worked time. So I've use both custom fields of TimingAndEstimationPlugin.

The screenshot shows 19 and 27 "remaining hours", looks like different plugins calculate in different ways?

The 27 is shown twice:

• workload -> your plugin
• total hours -> RoadmapHoursPlugin: sum(estimated_hours)

Also we can see "remaingin hours: 19h". It's RoadmapHoursPlugin too. remaining = sum(estimated_hours) - sum(worked_hours)

[anonymous]

The burndown chart looks wrong... you are burning up. :)

Have a look at my comments in #4256 (12/16/08). A burndown chart is a team's tool and from an agile process point of view it is unnecessary to report time spent. If you need something for billing in your organisation you probably need another tool. I personally recommend not mix two processes with different focus points (burndow chart = velocity improvements, billing reports = utilisation statements). What do you think?

[anonymous]

I don't want to use another tool but you are right: it's another process. Using TimingAndEstimationPlugin supports me with the availability to add working hours using SVN hook scripts. So developers don't need to open the ticket in a separate way.

It will be fine to combine burndown and SVN hook scripts. TimingAndEstimationPlugin supports only "adding hours" and not "count down remaining hours". May be it's a ticket for TimingAndEstimationPlugin? Or do have another idea?

[anonymous]

I am guessing that you work agile and you will not invoice your customer on a per task base, but on a per project base (something like 40h per person per week). If that is true you just need developers and managers to fill out a traditional time sheet where they say on which project they worked each day. Maybe you don't need to count individuals hours spent in form of a ticket system?

[anonymous]

Replying to anonymous:

I am guessing that you work agile and you will not invoice your customer on a per task base, but on a per project base (something like 40h per person per week).

That's true.

Maybe you don't need to count individuals hours spent in form of a ticket system?

I've had time to think over the last weeks. On the one hand, we have projects with fixed budget and time. I would like to support and validate the project plan using trac tickets with estimated work time. Maybe on requirements level or a technical components level. On the other hand we want to see how good the estimation is and need the availability to react early if the estimation is totally wrong. That's the level where I want to use a scrum based work. I will test a trac instance using your plugin in next project and a SVN hook script to edit the remaing hour. The SVN script of TimingAndEstimationPlugin seems to be simple.

[Joachim Hoessler]

I think the original question has been answered, so I can close this ticket.