Redmine

As a project manager, the percentage done field is problematic. I can't add them together or average them to determine the status of the overall project.

I much prefer the Fogbugz model where the original estimate is retained, a total of hours accumulated and the estimate of the number of hours needed to complete the issue.

There is a very good description and justification at:
http://www.joelonsoftware.com/items/2007/10/26.html

It would be really awesome if we could later add Evidence Based Scheduling

Jeff

Jeff Dombach wrote:

As a project manager, the percentage done field is problematic. I can't add them together or average them to determine the status of the overall project.

That's what the roadmap does. Percentage done isn't without use; It just goes sorely underused in most cases.

Now it's possible that it's underused because we don't have fancy reporting graphs, but from the projects I've seen, individual tickets tend to be small on the whole. What we end up tracking tends to be the rate at which new tickets are opened and old tickets are closed, not the progress of individual tickets. That would seem to be reflected in Redmine.org's use of the field.

The roadmap while showing the project is 90% complete does not really provide me with the knowledge if it will take two more hours or two more years.

Jeff

What needs to be done to have the Roadmap link? On my 0.8.0 install, none of the projects show the roadmap link.

Jeff

Jeff Dombach wrote:

What needs to be done to have the Roadmap link? On my 0.8.0 install, none of the projects show the roadmap link.

Do any of your projects have target versions? Without target versions, I don't think the roadmap tab appears.

Anywho, the roadmap percentage done is fine too keep, I think. It's just the percentage done on a per-ticket basis that I think is unnecessary and, as evidence shows, typically unused even by Redmine.org.

Thanks Brad, I just discovered I need to add versions for the roadmap to show.

However, if the roadmap shows a percentage of tickets closed, it is not very usable for me. As an example if there are 10 tickets, 9 finished that take 2 hours and 1 unfinished that will take 25 hours, is the version really 90% complete? As a project manager I calculate the version as being less then 50% complete. I am sure it is not hard for us to imagine the developers doing the 9 easy tasks first.

That is another part of the reason why I would disable the percentage done field (and in fact may hardcode to disable it). I added a custom field with remaining time and I will create reports based on it.

All that to say I am in favor of being able to disable the percentage done field on the issue. I would also like to be able to disable it on the roadmap and base the display on hours invested and hours remaining.

That's my two cents.

Jeff

Jeff Dombach wrote:

Thanks Brad, I just discovered I need to add versions for the roadmap to show.

However, if the roadmap shows a percentage of tickets closed, it is not very usable for me. As an example if there are 10 tickets, 9 finished that take 2 hours and 1 unfinished that will take 25 hours, is the version really 90% complete? As a project manager I calculate the version as being less then 50% complete. I am sure it is not hard for us to imagine the developers doing the 9 easy tasks first.

That is another part of the reason why I would disable the percentage done field (and in fact may hardcode to disable it). I added a custom field with remaining time and I will create reports based on it.

All that to say I am in favor of being able to disable the percentage done field on the issue. I would also like to be able to disable it on the roadmap and base the display on hours invested and hours remaining.

That's my two cents.

Jeff

Hrm. I suppose you could make an issue's time estimate a mandatory field, then show the target version percentage done as it pertains to time, yeah? I suppose in that context, you could auto-populate the percentage done based on the logged time (if there is any). I think there are some complexities here we're not considering.

Maybe the easier way of looking at it is seeing the roadmap showing the percentage of tickets closed instead of "how close we are to closing the target version". Hrm... not sure.

Brad Beattie wrote:

Does anyone use this field in their instances? It seems that Redmine.org doesn't really use it. Little Stream Software doesn't seem to be making much use of it.

Actually I use it all the time on longer issues. Most issues on my public projects are smaller issues so I just use the Status.

However, if the roadmap shows a percentage of tickets closed, it is not very usable for me. As an example if there are 10 tickets, 9 finished that take 2 hours and 1 unfinished that will take 25 hours, is the version really 90% complete? As a project manager I calculate the version as being less then 50% complete. I am sure it is not hard for us to imagine the developers doing the 9 easy tasks first.

I have a patch on my Redmine that takes the time estimate into account. So in your example the version would be 7% complete (9/10 issues complete)

• 9 issues = 2 hours
• 1 issue = 25 hours

2 hours spent / 27 hours total ~ 7.41%

I have a patch someone on here that illustrates how I have this setup. There's also #952 which talks about a plugin that will update % complete based on Status (New = 0%, In Progress = 50%, Closed = 100%)

Eric

Eric Davis wrote:

Brad Beattie wrote:

Does anyone use this field in their instances? It seems that Redmine.org doesn't really use it. Little Stream Software doesn't seem to be making much use of it.

Actually I use it all the time on longer issues. Most issues on my public projects are smaller issues so I just use the Status.

However, if the roadmap shows a percentage of tickets closed, it is not very usable for me. As an example if there are 10 tickets, 9 finished that take 2 hours and 1 unfinished that will take 25 hours, is the version really 90% complete? As a project manager I calculate the version as being less then 50% complete. I am sure it is not hard for us to imagine the developers doing the 9 easy tasks first.

I have a patch on my Redmine that takes the time estimate into account. So in your example the version would be 7% complete (9/10 issues complete)

• 9 issues = 2 hours
• 1 issue = 25 hours

2 hours spent / 27 hours total ~ 7.41%

I have a patch someone on here that illustrates how I have this setup. There's also #952 which talks about a plugin that will update % complete based on Status (New = 0%, In Progress = 50%, Closed = 100%)

Eric

Hrm. I can certainly see how the field could be useful (e.g. 4 hour time estimate, 7 hours spent, but only 80% complete). On the other hand, I'm concerned that when an end user is presented with too many fields, their attention becomes saturated and they ignore all non-required fields. :(

I agree about the number of fields the user will use. I also admit to being biased towards the Fogbugz model that requires time spent and time remaining. The percentage can then be automatically calculated. However, if the user only inputs percentage complete you can't calculate time spend and time remaining.

Brad, once someone starts working on an issue, the estimate is less valuable to me and the most valuable piece of info is how much longer will it take?

Hrm. I suppose you could make an issue's time estimate a mandatory field, then show the target version percentage done as it pertains to time, yeah? I suppose in that context, you could auto-populate the percentage done based on the logged time (if there is any). I think there are some complexities here we're not considering.

Yes, like what if the estimate was 5 hours and once started the developer determines it will take 10 hours. Auto populate won't work, however calculating percentage done is simple math logged time / (logged time + remaining time)

Eric, I am interested in the #952 plugin and will evaluate it for my install. What are the chances of your time estimate patch being integrated into trunk?

Regardless of the outcome, I think this is a great discussion and I appreciate hearing your opinions and voicing mine.

Jeff Dombach wrote:

As a project manager, the percentage done field is problematic. I can't add them together or average them to determine the status of the overall project.

I much prefer the Fogbugz model where the original estimate is retained, a total of hours accumulated and the estimate of the number of hours needed to complete the issue.

I recently got RedMine installed for my dev group and have hit this very wall. For my daily scrums I need to be able to leave the estimate alone so that we can track our success rate for sprint predictions and track our completion by the time spent vs. the remaining time. Having to do the math to find the right value to enter in for % complete is frustrating.

Anyone know of a plugin (or is anyone willing to write one) that changes % complete field to hours to completion? It can't be that hard; it's just the inverse of what it's currently doing.

Any thoughts appreciated!

Sam

++1

+1 - this would be awesome.

This discussion is pretty old. How is the latest version calculating the percentage completed of a version? Still by issues completed over the total, or by hours completed over the estimated?

Though this discussion rusted already but this can be helpful. Thanks.[[www.eaffordablecarinsurance.net ]]