Introducing Remaining Time field as method to track the remaining time to complete an issue
|Target version:||Candidate for next major release|
Currently, Redmine offers the possibility to estimate an issue and track the time spent on that issue using the log time module.Regarding the progress made on an issue, the only possibility is to use the "Done ratio" field, but there are some major disadvantages from our point of view:
1. update action requires multiple clicks
2. is not so accurate because if you calculate the remaining time using the formula "done ratio * estimated time" it means that the remaining time can't be greater than estimated time.
Having the following scenario:
- Issue with estimated time set to 4h
- During the development you discover that more hours (6h for example) are required
In order to correctly register the remaining time, you need to change the estimation from 4h to 6h and let the done ratio to 0%. Otherwise, the remaining time will be still 4h.
3. there is no relation between the log time and the done ratio field
Attached there are 2 patches:¶1. 01_add_remaining_hours_field_15945.patch:
- adds a new core field named "Remaining time" which behave almost like the Estimated time field
- automatically set the remaining time equal with estimated time when the remaining time is null and estimated time > 0.
- automatically set the remaining time to 0h when closing the issue.
2. update_issue_remaining_time.patch: the user can decide in the log time form to update or not the issue remaining hours. There are 3 options available:
- [default] adjust automatically: issue remaining time will be decreased with the logged number of hours.
- set to x hours
- do no update remaining time.
In this way, the issue remaining time can be tracked easily.
Also, we have in plan the following improvements:
- a new option for "Done Ratio" field to be calculated using the estimated time and remaining time
- better time tracking details in the version page.
#1 Updated by Marius BALTEANU over 4 years ago
- "can decide it the log time form what to updated or not the issue" -> "can decide in the log time form to update or not the issue"
- "issue remaining time with be decreased" -> "issue remaining time will be decreased"
#2 Updated by Marius BALTEANU over 4 years ago
- File 03_calculate_done_ratio_using_time.patch added
- File 04_add_remaining_time_to_version.patch added
Added last two patches on this topic.
Option to calculate the done ratio based on estimated and remaining hours. If the setting "calculated from subtasks" is set, the done ratio is calculated based on total estimated and total remaining hours.
Add remaining time under the estimated time in version page. This info is very useful especially when you use the versions as sprints and you need to move unfinished issues from a version to another version.
For example:¶Version 1 at the beginning:
Version estimated time: 54h.
Version remaining time: 54h.
At the end of the version, only Issue 1 and Issue 2 are finalized and Issue 3 and Issue 4 moved in version 2.Version 1 at the final:
Version estimated time: 54h.
Version remaining time: 8h.
Version estimated time: 49h (which is the sum of initial estimations).
Version remaining time: 28h (which is the real required time to finish the version).
#8 Updated by Marius BALTEANU over 4 years ago
Kosta H wrote:
Marius, these patches look great! Unfortunately they don't apply cleanly to Redmine 3.3.2, 3.3.1 or to `master`. If you have a git branch and publish it, I could help with rebasing. Would love to see this make it into core.
I'll upload a new version of the patches after the release of Redmine 3.4.0.
#9 Updated by Marius BALTEANU about 4 years ago
- File 01_add_remaining_hours_field_3.4.1.patch added
- File 02_add_remaining_time_to_log_time_3.4.1.patch added
- File 03_calculate_done_ratio_using_time_3.4.1.patch added
- File 04_add_remaining_time_to_version_3.4.1.patch added
For us (Zitec) it is a very important feature, so any feedback regarding the implementation is welcome. I'll be very happy to discuss the changes required to implement this feature in the core.
#10 Updated by Kosta H almost 4 years ago
Thanks so much Marius! Could the maintainers please weigh in on whether this might make it into 3.4.x or 3.5.x? I'd very much like to use these patches on my organization's Redmine instance but am hesitant to without knowing if they'll make it into the upstream branch.
#12 Updated by Marius BALTEANU over 3 years ago
Sudeep Halappa wrote:
This is exactly the feature I am looking for.
Apologies for the naive question. Will this feature work for Redmine 3.3.3.stable? That is the version we are currently using.
I didn't tests the patches against 3.3.3.stable, but you could try to apply the first version (uploaded by me in 2016).
#20 Updated by Marius BALTEANU over 1 year ago
Anders Thomsen wrote:
Marius, are you still determined to have this feature added? I'm evaluating if we should should apply the patch to our own instance but will avoid if we have to maintain it for all future versions.
Yes, I still think that it's a good improvement for Redmine, but the decision is at Jean-Philippe.
If so, do you plan to provide a patch for 4.1?
4.1 for sure, but I cannot say about other future versions.