Feature #3719
open
Automatical % Done regarding to Spent Time / Estimated Time
0%
Description
It seems, % Done could be calculated using two fields: Spent Time and Estimated Time.
Currently developer changes % Done himself, but what is considered as, for example, 50% Done? Does it mean, that there is written 50% of code lines to fix it, or spent 50% of estimated time, or developer just found solution, and "task is half-solved, when there is solution found"?
So, to resolve the ambiguity, and to not to make developer do excess actions, I suggest just calculate % Done as relation of Spent Time to Estimated Time.
Related issues
Updated by Thomas Pihl over 15 years ago
For some of our customers % Done is not the same as the correlation between spent and estimated time.
Some could argue that % Done should be spent time in relation to remaining time (this being a new estimate of the developer in how much time is needed to finish the task with his current knowledge).
Then you could compare spent+remaining time to estimate time to verify earlier estimate or to re-estimate the issue.
I think there are different solutions to this depending on the kind of methods used. You can quite easy write a plugin to calculate it your way if you like.
/T
Updated by Anton Nepomnyaschih over 15 years ago
Thomas, I think you are right. Maybe best way is to implement it as in JIRA. In JIRA there is shown progress bar with two lines - original estimation (blue), spent time (green) and remaining time (yellow). I think, it is very convenient. There is also popup tips when mouse hovers the bars - how much time is remaining. Please, look at http://screencast.com/t/cmthhOhA
Updated by Bruno Medeiros about 15 years ago
The current method of calculating % done is really too naive, but I think that use spent time is not a good idea.
People not always fill spent time, and often we spent more time the we estimate.
A good idea is to do a weighted average, weight the ticket by the estimated time instead of consider all tickets as being "equals".
For example, if we have 2 tickets, one with 2 hours of estimative and 100% done and other with 8 hours of estimative and 25% done, the progress bar should show 40% done instead of 63% (because tickets with more estimated time probably will take more time).
The only issue on that is to define a default value for the ticket that doesn't have the estimated time filled. Maybe it could be the average estimated time of all tickets, or something this way...
Updated by Eric Voisard about 15 years ago
I'm not sure there is always a linear relation between progresses made in the resolution of an issue and the time spent on it. In my opinion, %Done is % of work done, not % of time spent, and the owner of an issue is supposed to know better than an automated time averaging how far he is from the resolution of his issue.
I'd prefer to give the developer the ability to provide an estimate of his actual work, even if it's a rough estimation.
In that sense, there are many other factors than time that enter into consideration for such an estimation (hitting a snag, delays, human factors, etc) and a simple automated weighted average on time would be too rigid and it would be the naive solution.
We have those two fields Spent Time and Estimated Time, anybody can guestimate progresses from them. Why to spend the %Done additional parameter, which in some way provides additional information about an issue status, for showing information we already have.
Updated by Peter Nagy about 13 years ago
There is a setting
"Calculate the issue done ratio with"
where is dropdown field where the appropriate way of calculating % done can be correctly chosen.
Considering that Gant chart is being colored based on %, it would clearly notify the manager about the possible bottlenecks. I understand that owner of the task knows % done better and it may not be related 1:1 linear, but generally it would help to have this option (for us it would be very very efficient).