# Goal

OpenProject contains extensive project controlling functions (effort estimation, progress calculation, time recording and reporting). These existing functions are to be extended for use in hybrid large-scale projects in which a combination of agile and classic process models is used. In particular, it should be possible to record or calculate the following values of a work breakdown structure both top-down and bottom-up via a hierarchy.

# Relevant work package attributes

The following work package attributes are focussed on. They will also be renamed in this epic to make them more consistent with the project management frameworks.

<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Name 13.0</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Name 13.1</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Editable for parent work packages</p></th></tr></thead><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Estimated time</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Work</p></td><td class="op-uc-table--cell"><ul class="todo-list op-uc-list_task-list op-uc-list"><li class="op-uc-list--item"><label class="todo-list__label"><input type="checkbox" disabled="disabled" checked="checked"><span class="todo-list__label__description"></span></label></li></ul></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Remaining hours</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Remaining work</p></td><td class="op-uc-table--cell"><ul class="todo-list op-uc-list_task-list op-uc-list"><li class="op-uc-list--item"><label class="todo-list__label"><input type="checkbox" disabled="disabled" checked="checked"><span class="todo-list__label__description"></span></label></li></ul></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Progress (%)</p></td><td class="op-uc-table--cell"><p class="op-uc-p">% Complete</p></td><td class="op-uc-table--cell"><ul class="todo-list op-uc-list_task-list op-uc-list"><li class="op-uc-list--item"><label class="todo-list__label"><input type="checkbox" disabled="disabled" checked="checked"><span class="todo-list__label__description"></span></label></li></ul></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"></p></td><td class="op-uc-table--cell"><p class="op-uc-p"></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Currently values can not be edited for parent work packages</p></td></tr></tbody></table></figure>

## Support multiple units

* Recording and display in different units (hours, days, weeks, months)
* Definition and application of conversion coefficients between the different units (e.g. hours per working day, working days per week, working days per month, etc.)

## Calculation and display in work packages views

* The work package attributes for % Progress, Work and Remaining work Progress % value for a work package have two values:
* The value for the the parent work package itself.
* The total sum including all children work packages (including non-visible work packages).
* Both the values of the respective work package and the aggregated values including the sub-elements should be displayed in the cells.
* When filtering child work packages from the list the sum values after &quot;Σ&quot; remain unchanged. The percentage % for the filtered work packages in the sums row only includes the values of the filtered work packages. It does not include the values from children values which are filtered out.

# Out of Scope

* Display of historical values using the baseline comparison feature.
* Enhancements to time recording
* Extension of the work packages filter

# Visuals

<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/78899/content"></div><figcaption class="op-uc-figure--description">Full hierarchy</figcaption></figure>

<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/78898/content"></div><figcaption class="op-uc-figure--description">Child work packages filtered out</figcaption></figure>

# Acceptance criteria

* For the estimated time field it is possible to understand whether a value is empty (not set) or set to 0 h. This allows to better understand if an estimate has been made or not.
* Unset estimated time is included by 0 h into the calculation.

## Visuals

[https://www.figma.com/file/znrocQvFNLb5jXRXNo7oeD/Progress-estimation?node-id=52-9257](https://www.figma.com/file/znrocQvFNLb5jXRXNo7oeD/Progress-estimation?node-id=52-9257)

# Begin of the insertionPlanning

* ##50953
* ###50955
* ###50956
* ###50957
* ###50958
* ###50959
* ###50960
* ###50961
* ###50962
* ###50963

\------

* ##50954
* ###50964
* ###50965
* ###50966
* ###50967
* ###50968
* ###50969

#End of the insertion Open

* How does the progress calculation currently works? I tried setting estimated time and log some time spent. Neither progress (%) or remaining time changed.

> NL: Currently the attributes remaining hour and progress (%) are not connected. Both attributes are currenlty set manually.

* It looks like progress calculation is only children, and aggregated on parent. New implementation will have to take into account that parent can have its own progress too.
* Correct?

> NL: Correnct

* Unset estimates are not considered as 0h
* So how are they handled?

> NL: Don&#39;t know how is this currently handled. Let&#39;s think it through what makes sense.

* When changing &quot;Calculate the work package done ratio with&quot; &quot;Use work package status&quot;, and then changing status, nothing happens. It was a bit disappointing. I later read the docs and learned that statuses have to be configured to associate a progress to them.
* Couldn&#39;t this information be given through the UI somehow?

> NL: Good idea. We could add the pre-defined % values to the status label and to the status selection dialogue. We could also use Harvey balls to show the progress.

* vocabulary is not consistent: &quot;done ratio&quot; VS &quot;progress (%)&quot;

> NL: Yes. let&#39;s clean this up.

* some progress values could be seeded by default.

> NL: Good idea.

* As reported in ##49409, when using &quot;Use work package status&quot;, work packages with &quot;rejected&quot; status are still taken into account for calculating progress.
* Typical use: you can increase the progress of an epic by adding a lot of of rejected child packages to it. Nothing changed, but the progress increases.
* It sounds like a wrong behavior. Should it be changed? How?

> NL: Good point. We need to explore this. I agree it does not really make sense to include rejected work packages into the calculation. A workaround could be to manually remove rejected work packages from the work package hierarchy. Please keep in mind that the status &quot;Rejected&quot; is an individual configuraiton. This might be different for each installation. This implies that we need to have a new setting for work package status like &quot;not included in progress calculation&quot;.

* When using &quot;Use work package field&quot;, what happens when some progress % are set on work packages, and the setting is switched to &quot;Use work package status&quot;?

> NL: Never tried this. I would assume the manually entered values for progress % get lost. Can you please check the current behavior and update the docs accordings?

* In description: &quot;When filtering child work packages from the list the sum values after &quot;Σ&quot; remain unchanged. _The percentage % for the filtered work packages only includes the values of the filtered work packages._ It does not include the values from children values which are filtered out.&quot;
* So considering a work package with two children, one 100% complete, the other 0% complete. Depending on the view and filters, the parent can be shown as 0% complete, 50% complete, or 100% complete? How can this value be trusted by users if its value is so volatile?
* Or maybe it is referring to the totals row?

> NL: The specs were a little confusing. I updated it. It refers to the totals row. Good catch!

* There is an &quot;alternative concept&quot; section in the description. That&#39;s not clear.
* What is its purpose? What is the gif demonstrating? Should it be implemented? If not why keep it in the description?

> NL: Not sure why this is part of the description. I removed it.

* Using &quot;Calculate the work package done ratio with&quot; &quot;Use work package status&quot; seems out of scope for this epic.
* I assume this epic is focused on the &quot;Use work package field&quot; use case. The &quot;Use work package status&quot; is out of scope and should simply continue to work identically. It may be revised in a later work package. Correct?
* About roadmap and versions, the total progress of a version is calculated from the open/closed status of the work packages belonging to the version.
* I assume this is out of scope for this epic? It should simply continue to work the way it is working currently. Correct?
* &quot;Estimated Time&quot; can currently take 0h or be unset. having 0h behaves like being unset. When unset the estimated time is interpolated from the average estimated time of the sibling, so that having a 0% or 50% or 100% progress will have an impact on the parent progress %.
* This has the strange side-effect that a 0h task going from 0% to 100% complete will change the parent progress %.
* Same if a 0h child work package is marked as closed: the % progress will be considered 100% and the parent progress % will change accordingly (a bug prevent this update to be done immediately. It will take effect at next progress% calculation)
* Semantically, I think an estimated time of 0h for a task does not make any sense. Either it has a minimal duration, like 1h, or it is unset. &quot;0h&quot; should be a forbidden value, or should be converted back to an unset value.
* I&#39;d love to know more about when users set the time to 0h and what that means to them, to challenge if there are valid use cases for 0h.
* In this epic, the acceptance criteria indicate: &quot;_Unset estimated time is included by 0 h into the calculation._&quot;
* Does it mean that the estimated time interpolation will no longer occur, and that the completion of a 0h or unset work package will not impact the completion of the parent work package anymore? (when doing the completion average weighted by work, work of a work package being 0h means the completion is not taken into account)
* If so, how does it behave for a parent work package with children having only unset work? That means the progress can not be determined?
* Proposition: if all children have unset work, the behavior is the same as currently: the progress of the parent is the average of the children progress. if some children have set work, the behvior differs from currentyl: only the set ones are used to compute a completion average weighted by the work value.
* Currently, if Remaining Hours field is unset, when setting Estimated Time field, then the Remaining Hours field is automatically set to the same value.
* Where does this behavior come from? Should we keep it?
* When the backlog module is disabled, the remaining hours field is not present. In this case, setting Estimated Time and then enabling the backlog module will not set the Remaining Hours field.
* How is this field used in the backlog module?
* Can a work package hierarchy span on multiple projects?
* If so, what if some modules like backlog is enabled in one project, but not in another? Would the Remaining Hours field still be displayed?