Using 2 custom fields better than one

[Sébastien GISSINGER]

Could you use the notion of predicted time minus time worked equals remaining time.

• If prediction was too short, no soucy, the chart will go under 0 and we directly see that we are late.
• If prediction was too long then we are a good team ;-).

Doing that, you're plugin will be fully compatible with and without TimingAndEstimationPlugin which uses a custom field for predicted time and another one for time worked.
TimingAndEstimationPlugin plugin is also used by WorkLogPlugin which allow to record time worked on a ticket in live. With these 3 plugins together time machine is under heavy control.

• Futur Time with TimingAndEstimationPlugin
• Present Time with WorkLogPlugin
• Past Time with EstimationToolsPlugin

[Sébastien GISSINGER]

Sorry i understood like if i was living on pluton. You think good and i need to sleep now :-p.

[Sébastien GISSINGER]

mmm finally I think you should read this ticket.

[anonymous]

I also would like to see compatibility with TimingAndEstimationPlugin

[anonymous]

Comment: I don't understand what this enhancement is about.

[Sébastien GISSINGER]

The good points of this method (in my mind) :

• an estimation is made one time and one of the objective is to fit the best you can to that estimation. So you need to remember the initial number of hours you estimated to know if you're on time or not.
• I find easier to add a number of hour from 0 to a time passed field than making a substraction from a number of hours left.
• You have more possibilities of reporting with custom queries and standard report (making a substraction is easy on SQL even on text fields :p).
• It becomes compatible with two other plugins which one seems to be used by numerous people.

[anonymous]

My 2 cents: I think you don't need those extra numbers in order to see if you are in time or not. For planning purpose all you need are the remaining hours and the burndown chart (maybe with a diagonal line for expected hours, see #4073). Then you will see immediately if you are according to planning and also how good your planning was over the course of a whole sprint.

For a burndown chart with Scrum it is unnecessary to keep track of hours spent. You want to know how much hours need to be spent on an activity, not how many are already spent on it. A waterfal project manager might be intersted that someone worked overtime and all weekend, an agile project manager wants to see how much is left to accomplish the goals and nothing more. The general focus is on velocity and improving it.

[Sébastien GISSINGER]

You finally convinced me. TimingAndEstimationPlugin seems good but removing it resolved issues I had with my Trac installation and simplified it a lot. This plugin doesn't seems to be up to date.