Tickets have no field to estimate solution time

[dusty@…]

This would give a number of benefits, and among them:

• a (super)user that has the rights to change the priority of the tickets can rearrange them based on the time to handle them
• a milestone could show an expected time to be completed as the sum of the time of each ticket

[Emmanuel Blot]

#7936 marked as a duplicate

[Emmanuel Blot]

See also #710

[Christian Boos]

Related to FieldRefactoring.

[Christian Boos]

oops?

[eirik.midttun@…]

I would really like to see this feature implemented. But get it right. I think #7936 expressed the requirement better from my point of view. Just to point out a few things:

• I prefer Story Points, or something that expresses complexity. It is better for planning: Often a release date is set and I have to choose which tickets to finish before that date. With a Story Point it is easier to estimate if the work set for a milestone is realistic.
• In my case there is little room for negotiating release dates. The Story Points should show as a sum for a milestone, but I don't want the date to be calculated from this.
• Progress should be calculated from Story Points. The progress bar now shows the same progress weather the ticket took an hour or a week to solve.
• There is often confusion so to be clear: I do want estimation, I do not want time reporting. Estimation is good for planning, time reporting is just ​lame.

[Christian Boos]

While #1942 is about 'time', this is one is about 'duration'. The storage would also be in usecs, but the display would be in day / hours / minutes, as appropriate.

[Steffen Hoffmann]

Replying to cboos:

While #1942 is about 'time', this is one is about 'duration'. The storage would also be in usecs, but the display would be in day / hours / minutes, as appropriate.

Now, that we have 'date' and 'datetime', why not make 'duration' a third time field format? It might require more formatting options than current relative time formatting, but IMHO it nicely fits into the family.

[Philippe Cloutier <chealer@…>]

Thank you very much for reporting

You highlight a top issue, which unfortunately takes more time to solve than we would wish, notably for 2 reasons:

1. The necessity to distinguish initial estimates from the current estimates (when work was already started). While the latter are more useful, keeping the initial estimates can be a very useful indicator of estimation accuracy. In fact, for management, fully solving this also requires tracking time spent.
2. Multiple units are possible: Does "time" mean calendar time? Or is it in person-hours? Or person-days? Person-months?

Regarding #2, the best way to avoid such complication and facilitate prioritization is to calculate work in a currency. This is much better in organizations which rely on third parties to do the job. But this is not perfect. In particular, which currency should be used? And if we allow each instance to customize it, what should be done in an international project, such as Debian? And should we settle on the Euro, how do we reflect an estimate that a solution will take 1 person-hour, not knowing who will do the job? Do we assume the average wages in a level 4 country, knowing someone from a level 2 or 3 country might volunteer? Should we use a global average productivity? And if we do, if we assume a level ~3 wage of 15 €/hour for an issue estimated at 1 hour, but which ends up taking 4 hours from a level 4 volunteer worth 60 €/hour, does it make sense to estimate an issue at 15 € when it frequently ends up costing 240? Or do we need the field to support a cost range to reflect incertitude?

Do you insist on using a specific unit or form of estimation? Or do you simply consider the issue to be the lack of any way to track efforts/costs, regardless?

This comment is from Philippe "Chealer" Cloutier. I am subscribing to this ticket, but notifications seem to be broken, and I can neither display my full email address nor link to my contact information from this comment. My email address is available on Kune ni povos’s contact page. All of my comments and contributions in this ticket are offered under the terms of CC0 1.0 (unless otherwise noted).