プロジェクト

全般

プロフィール

Vote #77949

未完了

Introducing Remaining Time field as method to track the remaining time to complete an issue

Admin Redmine さんが3年以上前に追加. 3年以上前に更新.

ステータス:
New
優先度:
通常
担当者:
-
カテゴリ:
Issues planning_40
開始日:
2022/05/09
期日:
進捗率:

0%

予定工数:
category_id:
40
version_id:
32
issue_org_id:
24277
author_id:
107353
assigned_to_id:
0
comments:
24
status_id:
1
tracker_id:
2
plus1:
2
affected_version:
closed_on:
affected_version_id:
ステータス-->[New]

説明

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.

  1. there is no relation between the log time and the done ratio field

h2. 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.

!{width:60%; border: 1px solid grey;}remaining_time_field.png!

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.

!{width:60%; border: 1px solid grey;}remaining_time_in_time_log.png!

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.

There are multiple issues related to this feature:

  • DoneRatio_issues_overview - Section "Requests (and patch) for adding 3rd option "Use the logged and estimated time"
  • #22326 (implemented by the first patch)

journals

Please fix the following typos in the description:
* "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"
--------------------------------------------------------------------------------
Added last two patches on this topic.

h3. 03_calculate_done_ratio_using_time.patch

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.

h3. 04_add_remaining_time_to_version.patch

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.

h3. For example:

Version 1 at the beginning:
| Issue | Estimated | Remaining | Status |
| 1 | 10h | 10h | New |
| 2 | 15h | 15h | New |
| 3 | 15h | 15h | New |
| 4 | 14h | 14h | New |

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:
| Issue | Estimated | Remaining | Status |
| 1 | 10h | 0h | Closed |
| 2 | 15h | 0h | Closed |
| 3 | 15h | 4h | In Progress |
| 4 | 14h | 4h | In Progress |

Version estimated time: 54h.
Version remaining time: 8h.

Version 2 at the beginning:
| Issue | Estimated | Remaining | Status |
| 3 | 15h | 4h | In Progress |
| 4 | 14h | 4h | In Progress |
| 5 | 10h | 10h | New |
| 6 | 10h | 10h | New |

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).

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
+5!
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
I've updated the patch series to apply cleanly to the latest Redmine version (version:3.4.1) and current trunk (r16811).

For us ("Zitec":https://zitec.com) 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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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).
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
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.

If so, do you plan to provide a patch for 4.1?
--------------------------------------------------------------------------------
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.

--------------------------------------------------------------------------------
This feature looks nice. We want to be able to say how much work it remains to close a specific version of our software. I hope this will be included in a future Redmine release. Thank you.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> 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.

Is this feauture ever going to added to 4.2?
Or is there a 4.2 compatible version of the patch?
This is the only thing which is holding us back updating to 4.2 at the moment.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------


related_issues

relates,New,22326,New 'Remaining Time' field -- NOT related to the % done
relates,New,12762,Add option to calculate done ratio with the data from time tracking
relates,New,1671,Show a breakdown of estimated/spent/remaining time for a version
relates,New,13400,Calculate %done based on estimated and logged time
relates,New,5285,Introduce "Remaining time" column on "Issues list" page

Admin Redmine さんが3年以上前に更新

  • カテゴリIssues planning_40 にセット
  • 対象バージョンCandidate for next major release_32 にセット

他の形式にエクスポート: Atom PDF

いいね!0
いいね!0