# News from the Product Desk: Changes to progress tracking in 14.6 based on user feedback

In version 14.0, we made significant changes to the way that progress and work estimates are tracked in OpenProject. Since then, we have received extensive feedback from our user community telling us that the changes do not reflect their needs and sometimes even made things unnecessarily more complicated.

We greatly appreciate the time and effort put in by those who communicated their reservations to us. Your input is invaluable in helping us improve OpenProject. Based on that feedback, we have taken two main actions: We enhanced our feedback gathering process internally and, more importantly, decided to allow users to revert the changes made in version 14.0.

**Starting with OpenProject version 14.6, the % Complete field will once again be manually editable in work-based mode and % Complete totals will no longer require Work to be input.**

This blog article details how these changes might affect you.

## Upcoming adjustments

### Manually-editable % Complete in work-based mode

You will once again be able to manually enter a value for % Complete in work-based mode. This will be possible in both table view and work package details view.

As is the case today, *% Complete* will continue to be tied to *Work* and *Remaining Work*. What changes now is that those two values will no longer be required to enter *% Complete*. **This means that if you do not enter Work or Remaining work, the % Complete field will remain an independent, manually editable field and behave like it did pre-14.0.**

However, if you enter a value for *% Complete* and one other field (*Work* or *Remaining work*), the third one will automatically be derived based on the other two. In other words, there can be one value or three values but never just two values.

### How the three fields are connected

The *Work*, *Remaining work* and *% Complete* fields interact in predictable ways.

#### When no field is set

When a work package has none of these three values set, which field you enter first will determine if the others are derived as well:

**If you enter just % Complete**, nothing else is derived. Work and Remaining work remain empty.**If you enter just Work**, Remaining work is set to the same value as Work, and % Complete is set to 100%. You can remove these derived values manually if you want.**If you enter just Remaining work**, Work will be set to the same value as Remaining work and % Complete is set to 100%. You can remove these derived values manually if you want.

#### When one field is set

When only one field is set and you enter a value for a second field, the third is automatically derived:

**If you enter % Complete when Work is already set**, Remaining work is derived.**If you enter % Complete when Remaining Work is already set**, Work is derived.**If you enter Remaining work when Work is already set**(and vice-versa), % Complete is derived.

There are however, two important exceptions:

**If you enter a value for Remaining work that is higher than Work**, this will result in an error, since this is not logically possible.**If you enter a % Complete value of 100% when Remaining work has a value**, this will also result in an error, since Remaining work must be 0h when % Complete is 100%.

#### When all values are set

When all three values are present, the following table explains how changing one value affects the others:

**Increasing Work**

When you enter a value for *Work* that is higher than the current value, this adds the same value to *Remaining work* (since the total Work has increased by a certain amount), which then also updates *% Complete*:

Work | Remaining work | % Complete | |

Initial state | 100h | 60h | 40% |

Change | 200h | ||

Updated state | 200h | 160h | 20% |

**Decreasing Work**

If you decrease *Work*, *Remaining work* is lowered by the same amount:

Work | Remaining work | % Complete | |

Initial state | 100h | 60h | 40% |

Change | 50h | ||

Updated state | 50h | 10h | 80% |

If you decrease *Work* by less than the current value for *Remaining work*, then *Remaining work* will be set to 0h and *% Complete* to 100%.

Work | Remaining work | % Complete | |

Initial state | 100h | 60h | 40% |

Change | 30h | ||

Updated state | 30h | 0h | 100% |

**Changing Remaining work updates % Complete**

Work | Remaining work | % Complete | |

Initial state | 100h | 60h | 40% |

Change | 40h | ||

Updated state | 100h | 40h | 60% |

**Changing % Complete updates Remaining work**

Work | Remaining work | % Complete | |

Initial state | 100h | 60h | 40% |

Change | 60% | ||

% Complete updated | 50h | 40h | 60% |

### Status-based mode

These changes do not affect status-based progress calculation mode, in which the *% Complete* value for a work package is set by the status.

Please note however that since version 14.4, **you can freely assign any % Complete value for any status without being limited to 10-percent increments**. This was something that many of our users requested.

## Helpful hints on derived values

OpenProject 14.6 has also improved the *Work estimates and progress* pop-over to make things even clearer and easier to understand.

When you add, edit or remove a value for *Work*, *Remaining work* or *% Complete* and this affects the value of another field a helpful caption will indicate what has changed and why.

## New admin settings for calculation modes

Currently, when you display a hierarchy in table view, totals for the *% Complete* column only include values for work packages that also have a value for *Work*; those that do not are ignored. This was not ideal for some of our users, who wanted *% Complete* totals in a hierarchy without having to also enter values for *Work*.

Starting with version 14.6, this will once again be possible.

Administrators will see a new page under *Administration* → *Work packages* called **Progress tracking** with three settings:

**Progress calculation mode**lets you select between*work-based*and*status-based*modes.**Calculation of % Complete hierarchy totals**lets you pick between:- Weighted by work: The total
*% Complete*will be weighted against the*Work*of each work package in the hierarchy. Work packages without*Work*will be ignored (current behaviour) - Simple average:
*Work*is ignored and the total*% Complete*will be a simple average of*% Complete*values of work packages in the hierarchy

- Weighted by work: The total
**% Complete when status is closed**lets you chose what happens to*% Complete*when you close a work package (even in work-based mode):- No change, where the value of
*% Complete*will not change even when a work package is closed - Automatically set to 100%, where a closed work package is considered complete.

- No change, where the value of

## Migrating from 14.x

If you are upgrading to version 14.6 from version 14.x, none of your existing values for *Work*, *Remaining work* and *% Complete* will change. They will be preserved as is.

The only difference will be that *% Complete* will be manually editable again and you administrators have new settings available to them under *Administration* → *Work packages* → *Progress tracking*.

## Migrating from Pre-14.0

Some users told us they were refraining from updating to version 14.0 because they did not want their manually-entered *% Complete* values to be overwritten. If this is your case, we recommend upgrading directly to version 14.6. This will preserve your existing values of **Work** and **% Complete** in most cases.

The following cases detail what will happen in 14.6 in a number of different scenarios. They concern the field *Work*, *Remaining work* and *% Complete*.

### Case 1: Only one value set

If only one field out of three fields had a value set (*Work*, *Remaining work* or *% Complete*), one of two things can happen:

- If only
*% Complete*was set, nothing will change.*Work*and*Remaining work*remain empty. - If only
*Work*was set,*Remaining work*will be set to the same value as*Work*and*% Complete*will consequently be set to 0%. - If only
*Remaining work*was set,*Work*will be set to the same value as*Remaining work*and*% Complete*will consequently be set to 0%.

### Case 2: Two values set

If only two of the three fields had a value set (for example, only *Work* and *% Complete*; or *Work* and *Remaining work*), the third field will automatically be derived and a new value set in 14.0.

No existing value will be overwritten or changed. Some examples:

**Case 2.1: Remaining work was not set**

Work | Remaining work | % Complete | |

Pre-14.0 | 50h | 60% | |

New value set with migration | 20h | ||

Post 14.0 | 50h | 20h | 60% |

**Case 2.2: % Complete was not set**

Work | Remaining work | % Complete | |

Pre-14.0 | 50h | 20h | |

New value set with migration | 60% | ||

Post 14.0 | 50h | 20h | 60% |

**Case 2.3: Work was not set**

Work | Remaining work | % Complete | |

Pre-14.0 | 20h | 60% | |

New value set with migration | 50h | ||

Post 14.0 | 50h | 20h | 60% |

### Case 3: All three values set

If a work package had all three values, then there are two possible scenarios:

**Case 3.1: All three values are consistent**

If all three values are consistent and in sync (i.e, *% Complete* accurately reflects the relationship between *Work* and *Remaining work*), all existing values will be preserved and no changes made.

**Case 3.2: Remaining work is higher than Work**

Since *Remaining work* can never be higher than *Work*, it will be updated to preserve *% Complete:*

Work | Remaining work | % Complete | |

Pre-14.0 | 10h | 20h | 5% |

New value set with migration | 9.5h | ||

Post 14.0 | 10h | 9.5h | 5% |

**Case 3.3: Remaining work is lower than Work but % Complete is inconsistent**

If all three values exist and *Remaining work* is less than *Work* but the three values are inconsistent *(% Complete* does not reflect the relationship of *Work* to *Remaining work), % Complete* will be updated to make them consistent:

Work | Remaining work | % Complete | |

Pre-14.0 | 10h | 8 Std. | 50% |

New value set with migration | 5h | ||

Post 14.0 | 10h | 5h | 50% |

## Thank you for your feedback

These changes are a direct result of user feedback.

We want to extend our heartfelt thanks to everybody who took the time to reach out to us and explain why the changes made in 14.0 did not work for them. As an open source company, we are grateful for our engaged and passionate community of users.

We are also working to improve our internal processes for gathering and processing user feedback. This includes conducting more user research and conducting more tests as part of our design process. In the coming months, we will publish more information on how we plan to create even closer links with our user community.

In the meantime, as always, feel free to join our public OpenProject Community instance, where you can follow feature development in real time, create feature requests, report bugs and provide feedback.