Project

General

Profile

Actions
Copy link

Feature #2182

closed

Weighted version completion percentage

Added by Bobby Birks over 15 years ago. Updated about 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Roadmap
Target version:
0.9.0
Start date:
2008-11-13
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

Showing percentage of issue completion is a handy feature, but it would be nice to have the ability to see an estimation of work completion. It could be more intuitive in some cases. I would like to suggest this feature as at least an option to replace existing functionality, whether as an program, project, target version, or user-level preference. If so enabled, it should replace the current means of calculating version completeness percentages (and showing progress bars) wherever they appear.

As an example, a scattering of estimated times on Version Foo of a project:
Issue Estimated Status Percent Done Time Spent
1 16 Open 0% 0.0
2 4 Closed 100% 4.0
3 3 Open 40% 1.3
4 Unknown Open 0% 0.0
5 Unknown Open 50% 3.5
Total 23 8.8
As I understand it, the current methodology would consider each issue equally. So a 32 hour issue that's 50% done has equal value to a 0.5 hour issue that's 50% done. So in our case, we get
  1. 0% / 5 = 0%
  2. 100% / 5 = 20%
  3. 40% / 5 = 8%
  4. 0% / 5 = 0%
  5. 50% / 5 = 10%

This totals 38% done.

Unfortunately, I cannot think of any alternative that doesn't involve estimated time in some fashion, and that is an optional field.

While Redmine already displays total estimated/spent time for a version, using this directly could be flawed for several reasons. These reasons include that tracking time spent is not required either, and that there's nothing preventing spent time from exceeding estimated time.

Perhaps the most compatible option would be to split a version's issues into estimated and non-estimated. In the above example, that would be 3/5 estimated and 2/5 non-estimated issues.

The non-estimated issues would be given the same weight all issues are currently given. In this case, 20% (or one fifth).

The estimated issues are weighted relative to each other. There may be a more mathematically efficient representation, but below is a general idea:
  1. We have a total of 23 estimated hours for issues that were estimated.
    1. Weighted 16/23
    2. Weighted 4/23
    3. Weighted 3/23
  2. 60% of the versions issues have been estimated, so we must adjust the weights accordingly
    1. Weighted 48/115
    2. Weighted 12/115
    3. Weighted 9/115
  3. Now we consider the completion of the issue with regard to its weight
    1. 0%, no need to apply the weight
    2. Closed, no need to apply the weight
    3. 40% done, weighted by 9/115 gives 18/575, or about 3% completion of the overall project (instead of 8%)

In this example, the difference would be relatively small (33% instead of 38%). However, we have a target version in our Redmine installation which shows 38% completion, but by the above logic it would be closer to 10%. In our case it's due to fixing a large number of small, quick (1 hour or less) bugs before starting on big new features (ranging from 4-8 estimated hours on average).

Files

Download all files
percent_from_hours.diff (4.15 KB) percent_from_hours.diff Eric's patch for percent from estimated hours Eric Davis, 2008-11-14 06:04
version_completion.patch (1.6 KB) version_completion.patch Jean-Philippe Lang, 2008-11-14 18:48
perc.gif (949 Bytes) perc.gif Wrong percentage displayed Toni Kerschbaum, 2008-12-13 19:49
perc_bug_02.gif (816 Bytes) perc_bug_02.gif Toni Kerschbaum, 2008-12-13 19:53

Related issues

Related to Redmine - Feature #2139: Roadmap: use estimated time for calculating progressClosed2008-11-06

Actions
Related to Redmine - Defect #4682: Completed version with wrong progress bar statusConfirmed2010-01-28

Actions
Actions
Copy link

Also available in: Atom PDF